Программный продукт (ПП) представляет собой набор компьютерных программ, процедур и связанной с ними документации данных.
Жизненный цикл программного продукта - это период времени, начинающийся с момента принятия решения о необходимости создания ПП и заканчивающийся в момент его полного изъятия из эксплуатации.
Структуру жизненного цикла ПП, состав процессов, действия и задачи, которые должны быть выполнены во время создания ПП, определяет и регламентирует международный стандарт ISO/IEC 12207: 1995 «Information Technology - Software Life Cycle Processes» (ISO - International Organization for Standardization - Международная организация по стандартизации; IEC - International Electrotechnical Commission - Международная комиссия по электротехнике; название стандарта «Информационные технологии - Процессы жизненного цикла программ»).
Под процессом понимают совокупность взаимосвязанных действий, преобразующих входные данные в выходные. Каждый процесс характеризуется определенными задачами и методами их решения, а также исходными данными, полученными от других процессов, и результатами.
Каждый процесс разделен на набор действий, каждое действие - на набор задач. Запуск и выполнение процесса, действия или задачи осуществляются другими процессами.
В России, начиная с 1970-х годов, создание ПП регламентировалось стандартами ЕСПД (Единая система программной документации - серия ГОСТ 19.XXX), которые были ориентированы на класс относительно простых программ небольшого объема, создаваемых отдельными программистами. В настоящее время указанные стандарты устарели концептуально и по форме, их сроки действия закончились и дальнейшее использование этих стандартов нецелесообразно. В результате для каждого серьезного проекта приходится создавать комплекты нормативных и методических документов, регламентирующих процессы создания конкретного прикладного ПП, поэтому в отечественных разработках целесообразно использовать современные международные стандарты.
В соответствии со стандартом ISO/IEC 12207 все процессы жизненного цикла ПП разделены на три базовые группы (см. рис. 2.1):
Рисунок 2.1. Процессы жизненного цикла программного продукта
В соответствии с этим, а также опираясь на существующие стандарты, разработаем модель проектируемой нами информационной системы, автоматизирующей процесс продажи и учета продаж товаров на предприятии оптовой торговли ООО «РОСС».
Итак, под моделью жизненного цикла разработки ПП понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении жизненного цикла разработки ПП. Модель жизненного цикла зависит от специфики и сложности выполняемого проекта, а также от условий, в которых создается и будет функционировать ПП.
Стандарт ISO/IEC 12207 не предлагает конкретные модель жизненного цикла и методы разработки ПП. Положения стандарта являются общими для любых моделей жизненного цикла, методов и технологий разработки ПП.
Стандарт описывает структуру процессов жизненного цикла ПП, но не уточняет, как выполнить действия и задачи, включенные в эти процессы.
Модель жизненного цикла любого конкретного ПП определяет характер процесса его создания, который представляет собой совокупность упорядоченных во времени, взаимосвязанных и объединенных в этапы работ, выполнение которых необходимо и достаточно для создания ПП, соответствующего заданным требованиям. Под этапом разработки ПП понимается часть процесса создания ПП, ограниченная некоторыми временными рамками и заканчивающаяся выпуском конкретного продукта (моделей ПП, программных компонентов, документации), определяемого заданными для данной стадии требованиями. Этапы создания ПП выделяются по соображениям рационального планирования и организации работ, заканчивающихся заданными результатами.
Наибольшее распространение получили следующие модели жизненного цикла разработки ПП:
- каскадная модель, или «водопад» (Waterfall model);
- V-образная модель (V-shaped model);
- модель прототипирования (Prototype model);
- модель быстрой разработки приложений, или (RAD - Rapid Application Development model);
- многопроходная модель (Incremental model);
- спиральная модель (Spiral model).
Для разработки нашего программного продукта мы решил выбрать RAD-модель, т.к. именно этот вид модели жизненного цикла в большей степени отвечает всем требованиям, предъявляемым к разрабатываемой нами информационной системе. Такой выбор не случаен, он в основном связан с сущностью самой модели, более всех подходящей под наши требования.
Отметим, что в RAD-модели конечный пользователь играет решающую роль. В тесном взаимодействии с разработчиками он участвует в формировании требований и апробации их на работающих прототипах. Таким образом, в начале жизненного цикла на конечного пользователя выпадает большая часть работы, но в результате этого создаваемая система формируется более быстро.
В традиционном жизненном цикле разработки большую часть работы составляют программирование и тестирование. При автоматизации программирования и повторном использовании кода применяемых в RAD-модели, большую часть работы составляют планирование и проектирование.
На рисунке 2.2, поясняющем принцип RAD-модели, указаны этапы процесса разработки и отображено участие заказчиков (штриховая линия) на каждом из них.
Рисунок 2.2. RAD-модель жизненного цикла программного продукта
Модель включает в себя следующий фазы:
- составление требований и планирование - осуществляются с использованием так называемого метода совместного планирования требований (планирование работ по созданию ПП и составление требований к ПП выполняются одновременно), который заключается в структурном анализе и обсуждении решаемых задач;
- описание пользователя - проектирование ПП, выполняемое при непосредственном участии заказчика;
- создание - детальное проектирование, кодирование и тестирование ПП, а также поставка его заказчику;
- сопровождение - приемочные испытания, установка ПП и обучение пользователей.
Модель обладает следующими достоинствами:
- использование современных инструментальных средств позволяет сократить время цикла разработки;
- привлечение к работе заказчика сводит к минимуму риск того, что он останется недоволен готовым ПП;
- повторно используются компоненты уже существующих программ.
В то же время ей присущи и недостатки:
- если заказчики не могут постоянно участвовать в процессе разработки, то это может негативно сказаться на ПП;
- для работы нужны высококвалифицированные кадры, умеющие пользоваться современными инструментальными средствами;
- существует риск, что работа над ПП никогда не будет завершена, так как может быть зациклена, поэтому всегда надо вовремя остановиться.
Рассмотренную RAD-модель можно применять при разработке ПП, которые хорошо поддаются моделированию, когда требования к ПП хорошо известны, а заказчик может принять непосредственное участие в процессе разработки. Как раз то, что нужно для нашей информационной системы.
Теперь, окончательно определившись с моделью жизненного цикла и дав ей характеристику, обозначим и охарактеризуем процессы самого жизненного цикла, характерные для нашей информационной системы.
Начнем, с группы основных процессов. Основные процессы включают в себя набор определенных действий и связанных с ними задач, которые должны быть выполнены в течение жизненного цикла нашей информационной системы.
К основным относятся процессы:
- приобретения;
- поставки;
- разработки;
- эксплуатации;
-сопровождения.
В рамках данного дипломного проекта некоторые из вышеперечисленных процессов не актуальны, так наш проект будет ограничен в основном лишь рамками разработки. Но считаю необходимым кратко осветить и другие процессы жизненного цикла программного продукта, чтобы создать общую картину и общее представление о жизненном цикле информационной системы.
Итак, процесс приобретения (acquisition process) охватывает действия заказчика по приобретению ПП. К этим действиям относятся:
- инициирование приобретения;
- подготовка заявочных предложений;
- подготовка и корректировка договора;
- надзор за деятельностью поставщика;
- приемка и завершение работ.
Инициирование приобретения включает в себя следующие задачи:
- определение заказчиком своих потребностей в приобретении, разработке или усовершенствовании системы, ПП или услуг;
- анализ требований к системе;
- принятие решения относительно приобретения, разработки или усовершенствования существующего ПП;
- проверку наличия необходимой документации, гарантий, сертификатов, лицензий и поддержки в случае приобретения ПП;
- подготовку и утверждение плана приобретения, включающего в себя требования к системе, тип договора, ответственность сторон и т.д.
Согласно нормативным документам понятие «система» можно интерпретировать двояко. В одном случае под системой понимают совокупность аппаратных, программных, материальных и людских ресурсов, услуг и данных, одним словом, все то, что потребует разработки или покупки.
В другом случае система - это совокупность конечных продуктов, которые будут действовать совместно, и вспомогательных продуктов, необходимых для разработки, поставки, обучения и т.д.
Отметим, что в нашем случае инициирование приобретения можно сопоставить с проведенным нами анализом существующей системы («КАК ЕСТЬ»), выявлением в ней с позиции автоматизации бизнес-процессов «слабых» мест.
Подготовка заявочных предложений подразумевает разработку и вставление предложений, которые должны содержать:
- требования к разрабатываемой или покупаемой системе;
- перечень необходимых ПП;
- условия и соглашения;
- технические ограничения (например, указание конкретной среды функционирования системы).
Заявочные предложения направляются выбранному поставщику (или нескольким поставщикам в случае проведения тендера). Поставщиком является организация, которая заключает договор с заказчиком на поставку системы, ПП или программной услуги на условиях, оговоренных в договоре.
Применительно к нашему проекту здесь можно говорить о подготовке требований к проектируемой информационной системе, которое нами также проводилось.
Подготовка и корректировка договора включают в себя следующие задачи:
- определение заказчиком процедуры выбора поставщика, содержащей критерии оценки предложений возможных поставщиков;
- выбор конкретного поставщика на основе анализа предложений;
- подготовку и заключение договора с поставщиком;
- внесение изменений (при необходимости) в договор в процессе его выполнения.
Надзор за деятельностью поставщика осуществляется в соответствии с действиями, предусмотренными в процессах совместной оценки и аудита.
В процессе приемки подготавливаются и выполняются необходимые тесты.
Завершение работ по договору осуществляется в случае удовлетворения всем условиям приемки.
Естественно, что в никакие договорные отношения в нашем случае никто не вступал, но все же, отметить данные этапы стоило, т.к. они характерны для «реальных» проектов, необходимых организациям, заказ на которые они производят у специализированных фирм.
Следующим этапом является процесс поставки (supply process), он охватывает действия и задачи поставщика при снабжении заказчика ПП или услугой. К этим действиям относятся:
- инициирование поставки;
- подготовка ответа на заявочные предложения;
- подготовка договора;
- планирование;
- выполнение и контроль;
- проверка и оценка;
- поставка и завершение работ.
Инициирование поставки заключается в рассмотрении поставщиком заявочных предложений и принятии решения согласиться с выставленными требованиями и условиями или предложить свои.
Подготовка ответа на заявочные предложения выполняется в соответствии с принятыми решениями в результате инициирования поставки.
Подготовка договора осуществляется после выбора заказчиком конкретного поставщика.
Планирование выполняется после заключения договора и включает в себя следующие задачи:
- принятие решения поставщиком относительно выполнения работ своими силами или с привлечением субподрядчика;
- разработку поставщиком плана управления проектом, содержащего организационную структуру проекта, разграничение ответственности, технические требования к среде разработки и ресурсам, управление субподрядчиками и т.д.
Субподрядчик - это организация, индивидуум или корпорация, заключившие договор с поставщиком на исполнение части работ, которые поставщик должен выполнить по договору с заказчиком.
Выполнение и контроль включают в себя задачи, связанные с выполнением поставщиком взятых на себя обязательств по поставке, разработке или усовершенствованию системы, ПП или услуг и контролем за этим выполнением.
Проверка и оценка выполняются в соответствии с действиями, предусмотренными в процессах совместной оценки и аудита.
Поставка и завершение работ выполняются в соответствии с оговоренными в процессе инициирования действиями по приемке и завершению работ.
Собственно мы подошли к самому значимому для нас процессу, процесс разработки (development process). Он охватывает действия и задачи разработчика и предусматривает следующие основные направления работ:
- создание ПП и его компонентов в соответствии с заданными требованиями, включая оформление проектной и эксплуатационной документации;
- подготовку материалов, необходимых для проверки работоспособности и качества ПП;
- подготовку материалов, необходимых для организации обучения персонала, и т.д.
Следующим процессов является процесс эксплуатации (operation process), он охватывает действия и задачи оператора - организации, занимающейся эксплуатацией разработанного ПП или системы. К этим действиям относятся:
- подготовительная работа;
- эксплуатационное тестирование;
- эксплуатация системы;
- поддержка пользователей.
Подготовительная работа предполагает выполнение оператором следующих задач:
- планирование работ, выполняемых в процессе эксплуатации, и установку эксплуатационных стандартов;
- определение процедур локализации и разрешения проблем, возникающих в процессе эксплуатации.
Эксплуатационное тестирование выполняется для каждой очередной версии ПП, после чего она передается в эксплуатацию.
Эксплуатация системы осуществляется в предназначенной для этого среде в соответствии с пользовательской документацией.
Поддержка пользователей заключается в оказании помощи и консультациях при обнаружении ошибок в процессе эксплуатации ПП.
Процесс сопровождения (maintenance process) охватывает действия и задачи сопровождающей организации (службы сопровождения). Данный процесс активизируется при изменениях (модификациях) ПП и соответствующей документации, вызванных возникшими проблемами или потребностями в модернизации либо адаптации ПП. В соответствии со стандартом IEEE-90 (IEEE -Institute of Electrical and Electronics Engineers - Институт инженеров по электротехнике и электронике) под сопровождением понимается внесение изменений в ПП в целях исправления ошибок, повышения производительности либо адаптации к изменившимся условиям работы или требованиям.
Таким образом, нам удалось кратко охарактеризовать каждый из основных процессов, теперь перейдем к характеристики вспомогательных процессов.
Отметим, что основной целью вспомогательных (поддерживающих) процессов является создание надежного, полностью удовлетворяющего требованиям заказчика ПП в установленные договором сроки. К вспомогательным относятся процессы:
- документирования;
- управления конфигурацией;
- обеспечения качества;
- верификации;
- аттестации;
- совместной оценки;
- аудита;
- разрешения проблем.
Процесс документирования (documentation process) предусматривает формализованное описание информации, созданной в течение жизненного цикла ПП. Данный процесс состоит из набора действий, с помощью которых планируют, проектируют, разрабатывают, выпускают, редактируют, распространяют и сопровождают документы, необходимые для всех заинтересованных лиц, таких как руководство, технические специалисты и пользователи системы.
Процесс документирования включает в себя:
- подготовительную работу;
- проектирование и разработку документации;
- выпуск документации;
- сопровождение.
Подготовительная работа требуется для определения и согласования необходимого перечня документов и документируемых процедур, выполняемых в процессе жизненного цикла ПП.
Проектирование и разработка документации выполняются в процессе работы над ПП и завершаются одновременно с завершением его жизненного цикла.
Выпуск документации осуществляется по мере ее готовности в ходе разработки ПП и его дальнейшего сопровождения.
Сопровождение включает в себя действия по корректировке и обновлению документации в процессе жизненного цикла ПП.
Процесс управления конфигурацией (configuration management process) предполагает применение административных и технических процедур на всем протяжении жизненного цикла ПП для выполнения следующих действий:
- определение состояния компонентов ПП;
- управление модификациями ПП;
- описание и подготовка отчетов о состоянии компонентов ПП и запросов на модификацию;
- обеспечение полноты, совместимости и корректности компонентов ПП;
- управление хранением и поставкой ПП.
Согласно стандарту IEEE-90 под конфигурацией программного продукта понимается совокупность его функциональных и физических характеристик, установленных в технической документации и реализованных в ПП.
Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПП на всех стадиях жизненного цикла. Общие принципы и рекомендации по управлению конфигурацией ПП отражены в стандарте ISO/IEC CD 12207-2: 1995 «Information Technology - Software Life Cycle Processes. Part 2. Configuration Management for Software» («Информационные технологии - Процессы жизненного цикла про-грамм. Часть 2. Управление конфигурацией программ»).
Процесс управления конфигурацией включает в себя:
- подготовительную работу;
- идентификацию конфигурации;
- контроль конфигурации;
- учет состояния конфигурации;
- оценку конфигурации; управление выпуском и поставку.
Подготовительная работа заключается в планировании управления конфигурацией.
Идентификация конфигурации устанавливает правила, с помощью которых можно однозначно идентифицировать и различать компоненты ПП и их версии. Кроме того, каждому компоненту и его версиям соответствует однозначно обозначаемый комплект Документации, В результате создается база для однозначного выбора версий компонентов ПП и манипулирования ими, которая использует ограниченную и упорядоченную систему символов, идентифицирующих различные версии программного продукта.
Контроль конфигурации предназначен для систематической оценки предполагаемых модификаций ПП и координированной их реализации с учетом эффективности каждой модификации и затрат на ее выполнение. При этом обеспечивается контроль состояния и развития компонентов ПП и их версий, а также адекватность реально изменяющихся компонентов и их комплектной документации.
Учет состояния конфигурации представляет собой регистрацию состояния компонентов ПП, подготовку отчетов обо всех реализованных и отвергнутых модификациях версий компонентов ПП. Совокупность отчетов обеспечивает однозначное отражение текущего состояния системы и ее компонентов, а также ведение истории модификации.
Оценка конфигурации заключается в оценке функциональной полноты компонентов ПП, а также соответствия их физического состояния текущему техническому описанию.
Управление выпуском и поставка включают в себя изготовление эталонных копий программ и документации, их хранение и поставку пользователям в соответствии с порядком (процессом), принятым в организации.
Процесс обеспечения качества (quality assurance process) обеспечивает соответствующие гарантии того, что ПП и процессы его жизненного цикла соответствуют заданным требованиям и утвержденным планам. Под качеством ПП понимается совокупность свойств, которые характеризуют способность ПП удовлетворять заданным требованиям.
Для получения достоверных оценок создаваемого ПП процесс обеспечения его качества должен происходить независимо от субъектов, непосредственно связанных с разработкой ПП. При этом могут использоваться результаты других вспомогательных процессов, таких как верификация, аттестация, совместная оценка, аудит и разрешение проблем.
Процесс обеспечения качества включает в себя:
- подготовительную работу;
- обеспечение качества продукта;
- обеспечение качества процесса;
- обеспечение прочих показателей качества системы.
Подготовительная работа заключается в координации с другими вспомогательными процессами и планировании самого процесса обеспечения качества с учетом используемых стандартов, методов, процедур и средств.
Обеспечение качества продукта подразумевает гарантирование полного соответствия ПП и его документации требованиям заказчика, предусмотренным в договоре.
Обеспечение качества процесса предполагает гарантирование соответствия процессов жизненного цикла ПП, методов разработки, среды разработки и квалификации персонала условиям договора, установленным стандартам и процедурам.
Обеспечение прочих показателей качества системы осуществляется в соответствии с условиями договора и стандартом качества ISO-9001.
Процесс верификации (verification process) состоит в доказательстве того, что ПП, являющиеся результатами некоторого действия, полностью удовлетворяют требованиям или условиям, зависящим от предшествующих действий.
Верификация может проводиться самим исполнителем или другим специалистом данной организации, а также специалистом сторонней организации. Тут возможны различные вариации, в соответствии с которыми можно говорить о различной степени независимости верификации. Если процесс верификации осуществляется организацией, не зависящей от поставщика, разработчика, оператора или службы сопровождения, то он называется процессом независимой верификации.
Процесс верификации включает в себя:
- подготовительную работу;
- собственно верификацию.
Подготовительная работа заключается в координации с другими вспомогательными процессами и планировании самого процесса верификации с учетом используемых стандартов, методов, процедур и средств. Для повышения эффективности верификация должна как можно раньше интегрироваться с использующими ее процессами (такими как поставка, разработка, эксплуатация или сопровождение).
Верификация в узком смысле означает формальное доказательство правильности ПП. Данный процесс может включать в себя анализ, оценку и тестирование.
В процессе верификации проверяются:
- непротиворечивость требований к системе и степень учета потребностей пользователей;
- возможности поставщика выполнить заданные требования;
- соответствие выбранных процессов жизненного цикла ПП условиям договора;
- адекватность стандартов, процедур и среды разработки процессам жизненного цикла ПП;
- соответствие проектных спецификаций ПП заданным требованиям;
- корректность описания в проектных спецификациях входных и выходных данных, последовательности событий, интерфейсов, логики и т.д.;
- соответствие кода проектным спецификациям и требованиям;
- тестируемость и корректность кода, его соответствие принятым стандартам кодирования;
- корректность интеграции компонентов ПП в систему;
- адекватность, полнота и непротиворечивость документации.
Процесс аттестации (validation process) предусматривает определение полноты соответствия заданных требований к создаваемой системе или ПП функциональному назначению последних. Под аттестацией обычно понимают подтверждение и оценку достоверности проведенного тестирования ПП. Аттестация должна гарантировать полное соответствие ПП спецификациям, требованиям и документации, а также возможность его безопасного и надежного применения пользователем. Аттестацию рекомендуется выполнять путем тестирования во всех возможных ситуациях и использовать при этом независимых специалистов. Аттестация может проводиться на начальных стадиях жизненного цикла программного продукта или как часть работы по приемке программного продукта.
Аттестация так же, как и верификация, может осуществляться с различными степенями независимости. Если процесс аттестации выполняется организацией, не зависящей от поставщика, разработчика, оператора или службы сопровождения, то он называется процессом независимой аттестации.
Процесс аттестации включает в себя:
- подготовительную работу;
- собственно аттестацию.
Подготовительная работа заключается в координации с другими вспомогательными процессами и планировании самого процесса аттестации с учетом используемых стандартов, методов, процедур и средств.
Аттестация позволяет определить полноту соответствия разработанных требований к создаваемому ПП или системе функциональному назначению последних.
Процесс совместной оценки (joint review process) предназначен для оценки состояния работ по проекту и ПП, создаваемому при выполнении данных работ. Он заключается в основном в контроле за планированием и управлением ресурсами, персоналом, аппаратурой и инструментальными средствами проекта.
Оценка выполняется как на уровне управления проектом, так и на уровне его технической реализации и проводится в течение всего срока действия договора. Данный процесс может выполняться двумя любыми сторонами, участвующими в договоре, при этом одна сторона проверяет другую.
Процесс совместной оценки включает в себя:
- подготовительную работу;
- оценку управления проектом;
- техническую оценку.
Подготовительная работа заключается в координации с другими вспомогательными процессами и планировании самого процесса оценки с учетом используемых стандартов, методов, процедур и средств.
Оценка управления проектом позволяет определить текущее состояние хода выполнения работ по оцениваемому проекту.
Техническая оценка проекта позволяет определить текущее состояние хода выполнения работ по технической реализации проекта.
Процесс аудита (audit process) представляет собой определение соответствия требованиям, планам и условиям договора как хода выполнения работ по созданию ПП, так и самого ПП. Аудит может выполняться двумя любыми сторонами, участвующими в договоре, когда одна сторона проверяет другую.
Аудит служит для установления соответствия реальных работ и отчетов требованиям, планам и контракту. Аудиторы (ревизоры) не должны иметь прямой зависимости от разработчиков ПП. Они оценивают состояние работ, использование ресурсов, соответствие документации спецификациям и стандартам, корректность проводимого тестирования.
Процесс аудита включает в себя:
- подготовительную работу;
- собственно аудит.
Подготовительная работа заключается в координации с другими вспомогательными процессами и планировании проведения аудиторских проверок с учетом установленных требований, планов, условий договора и контракта.
Аудит - это ревизия (проверка), проводимая компетентным органом (лицом) в целях обеспечения независимой оценки степени соответствия ПП или проводимых работ установленным требованиям, планам, условиям договора и контракта.
Процесс разрешения проблем (problem resolution process) пре-дусматривает анализ и решение проблем (включая выявленные несоответствия), обнаруженных в ходе разработки, эксплуатации, сопровождения и других процессов, независимо от их происхождения или источника. Каждая обнаруженная проблема должна быть идентифицирована, описана, проанализирована и разрешена.
Процесс разрешения проблем включает в себя:
- подготовительную работу;
- собственно разрешение проблем.
Подготовительная работа заключается в координации с другими вспомогательными процессами и планировании работ по выявлению, анализу и решению возникших проблем.
Разрешение проблем проводится на протяжении всего жизненного цикла ПП и включает в себя действия по выявлению различных проблем или несоответствий их анализу и устранению.
Осветив вопрос вспомогательных жизненных циклов, нам удалось подойти к анализу организационных процессов.
Итак, основной целью организационных процессов является организация процесса разработки надежного, полностью удовлетворяющего требованиям заказчика ПП в установленные договором сроки и управление этим процессом.
К организационным относятся процессы:
- управления;
- создания инфраструктуры;
- усовершенствования;
- обучения.
Процесс управления (management process) состоит из действий и задач, которые могут выполняться любой стороной, управляющей своими процессами. Данная сторона (менеджер) отвечает за управление выпуском продукта, проектом и задачами соответствующих процессов, таких как приобретение, поставка, разработка, эксплуатация, сопровождение и др.
Процесс управления включает в себя:
- инициирование и определение области управления;
- планирование;
- управление работами по созданию ПП и контроль за их выполнением;
- проверку и оценку;
- завершение работ.
При инициировании и определении области управления менеджер должен определить необходимые для управления ресурсы (персонал, оборудование и технология) и убедиться, что они имеются в его распоряжении, причем в достаточном количестве.
Проведя аналогию и спроецировав данный процесс жизненного цикла программного продукта на нашу информационную систему, можно сказать, что мною были проведены следующие работы: изучены технические возможности персонального компьютера, в соответствии с которыми был выбран самый оптимальный вариант среды обработки.
Планирование подразумевает выполнение, как минимум, следующих задач: составление графиков выполнения работ; оценку затрат; выделение требуемых ресурсов; распределение ответственности; оценку рисков, связанных с конкретными задачами; создание инфраструктуры управления.
Управление работами по созданию ПП и контроль за их выполнением осуществляются в соответствии с результатами планирования.
В ходе выполнения работ обязательно должны выполняться регулярная проверка их выполнения и оценка достигнутых результатов. При необходимости по результатам проверки и оценки могут быть внесены корректировки в ход выполнения работ.
Завершение работ происходит после выполнения всех обязательств, взятых поставщиком перед заказчиком в соответствии с заранее оговоренными процедурами.
Процесс создания инфраструктуры (infrastructure process) охватывает выбор и поддержку (сопровождение) технологии, стандартов и инструментальных средств, выбор и установку аппаратных и программных средств, используемых для разработки, эксплуатации или сопровождения ПП. Инфраструктура должна модифицироваться и сопровождаться в соответствии с изменениями требований к соответствующим процессам. Инфраструктура, в свою очередь, является одним из объектов управления конфигурацией.
Процесс создания инфраструктуры включает в себя:
- подготовительную работу;
- создание инфраструктуры;
- сопровождение инфраструктуры.
Подготовительная работа заключается в координации с другими организационными процессами и планировании работ по созданию инфраструктуры с учетом выбранных технологий, стандартов, инструментальных, программных и аппаратных средств.
Создание инфраструктуры включает в себя все действия по разработке в соответствии с выбранной концепцией и планом инфраструктуры для выполнения работ по созданию ПП.
Сопровождение инфраструктуры вызвано необходимостью со-провождения ПП и возможными модификациями продукта в соответствии с изменившимися требованиями к нему.
Процесс усовершенствования (improvement process) предусматривает оценку, измерение, контроль и усовершенствование процессов жизненного цикла ПП. Данный процесс включает в себя:
- создание процесса;
- оценку процесса;
- усовершенствование процессов жизненного цикла ПП.
Создание процесса усовершенствования процессов жизненного цикла ПП позволяет на основе контроля за ходом выполнения процессов жизненного цикла, измерения характеристик и оценки полученных результатов существенно улучшить качество разрабатываемого ПП и сократить сроки его создания.
Оценка процесса разработки ПП позволяет выявить его сильные и слабые стороны и на основе полученных результатов провести необходимые улучшения.
Усовершенствование процессов жизненного цикла ПП направлено на повышение производительности труда всех участвующих в них специалистов за счет совершенствования используемой технологии, методов управления, выбора инструментальных средств и обучения персонала. Усовершенствование основано на анализе Достоинств и недостатков каждого процесса. Такому анализу в большой степени способствует накопление в организации исто-рической, технической, экономической и иной информации по реализованным проектам.
Процесс обучения (training process) охватывает первоначальное обучение и последующее постоянное повышение квалификации персонала. Приобретение, поставка, разработка, эксплуатация и сопровождение программного продукта в значительной степени зависят от уровня знаний и квалификации персонала. Например, Разработчики ПП должны пройти необходимое обучение методам и средствам программной инженерии. Содержание процесса обучения определяется требованиями к проекту. Для этого процесса Должны быть запланированы необходимые ресурсы и технические средства обучения. Кроме того, должны быть разработаны и представлены методические материалы, необходимые для обучения пользователей в соответствии с учебным планом.
Процесс обучения включает в себя:
- подготовительную работу;
- разработку учебных материалов;
- реализацию плана обучения.
Подготовительная работа заключается в координации с другими организационными процессами и планировании работ по созданию плана обучения и повышения квалификации.
Разработка учебных материалов является неотъемлемой частью процесса обучения, так как позволяет существенно повысить его эффективность и качество.
Реализация плана обучения должна осуществляться непрерывно в течение всего времени, для которого этот план разработан.
Таким образом, мы выделили и охарактеризовали процессы и этапы жизненного цикла программных продуктов. На основании полученных знаний попытаемся построить структуру жизненного цикла разрабатываемой нами информационной системы, а также обозначим характерные для нее процессы. Схематично это можно представить следующим образом (см. рис. 2.3):
Рисунок 2.3. Основные этапы жизненного цикла АИС учета продажи товаров на оптовом предприятии ООО «РОСС»
Проведем характеристику каждого из процессов по ранее разработанной нами схеме классификации бизнес процессов, т.е. определив основные элементы:
- входной поток;
-выходной поток;
- участники;
- управление.
Начнем с первого этапа, т.е. этапа составления требований и планирования (см. рис. 2.4):
Рисунок 2.4. Характеристика первого этапа жизненного цикла
Теперь рассмотрим следующий этап жизненного цикла проектируемой нами информационной системы, посвященный описанию пользователя (см. рис. 2.5):
Рисунок 2.5. Характеристика второй этапа жизненного цикла
Следующим этапом является этап непосредственного создания самой автоматизированной информационной системы, охарактеризуем его (см. рис. 2.6):
Рисунок 2.6. Характеристика третьего этапа жизненного цикла
Итак, мы подошли к заключительному этапу жизненного цикла нашей автоматизированной информационной системы, а именно к этапу ее сопровождения (см. рис. 2.7):
Рисунок 2.7. Характеристика четвертого этапа жизненного цикла
Таким образом, нам удалось дать краткую характеристику каждому из выделенных этапов жизненного цикла разрабатываемой нами автоматизированной информационной системе для ООО «РОСС».
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
К сожалению, как и в любом другом деле, в процессе жизненного цикла создаваемой нами информационной системы нельзя обойтись без разного рода рисков. Но лучше предотвратить их возникновение, чем устранять последствия. Выделим основные риски, характерные для каждого этапа жизненного цикла нашей информационной системы и обозначим меры их предотвращения.
Начнем с самой первой, предпроектной стадии. Для данной стадии характерны такие риски, как:
- Риск персонала со стороны заказчика и исполнителя;
- Риск нарушения методологии ведения проекта.
Рассмотрим каждый из них более подробно.
Итак, среди основных факторов первого риска можно выделить следующий:
- привлечение к проекту неопытных бизнес-аналитиков и ИТ-консультантов;
- включение в команду работы над проектом со стороны заказчика случайных сотрудников, а не ключевых участников бизнес-процессов, подлежащих автоматизации;
- ошибочные выводы, сделанные на основе анализа данных, неверная интерпретация данных, прошедших обработку;
- отсутствие у руководства предприятия единой целостной стратегии в области информационных технологий;
- непонимание руководством основных целей задач проекта;
- стремление скрыть реальные результаты работы того или иного сотрудника со стороны заказчика;
- некомпетентность сотрудников в рамках выполняемой работы;
- неправильный подбор персонала в рабочую группу над проектом;
- отсутствие мотивации и заинтересованности у функциональных менеджеров проекта;
- не налаженная система коммуникаций между участниками рабочей группы;
- негативное отношение персонала к проекту;
- необдуманный план ведения работ.
Все это может привести к плачевным результатом, во избежание чего, можно противопоставить следующее:
- активное вовлечение высшего руководства в проект, активное взаимодействие с ним в ходе проекта и своевременное принятие решений;
- активное участие в проекте ведущих специалистов заказчика, ответственных за исполнение основных процессов;
- четко сформулированные цели и критерии успеха внедренческого проекта;
- участие профессиональных консультантов со стороны заказчика, а также сотрудников предметных подразделений со стороны исполнителя;
- проработка общей стратегии автоматизации предприятия;
- четкое разъяснение целей, материальное стимулирование, пропаганда позитивного примера среди участников на время реализации проекта;
- организация рабочих мест и процедур взаимодействия таким образом, чтобы члены проектной команды могли постоянно и беспрепятственно общаться друг с другом;
- стабильный состав рабочий группы в течение всего проекта;
- отбор людей в проектную команду по принципу их личной заинтересованности в успехе внедрения.
Следующих из выделанных нами на данном этапе жизненного цикла рисков является риск нарушения методологии ведения проекта.
Основным фактором возникновения данного риска является необдуманное описания и утверждения документов, содержащих информацию об интересах сторон и состоянии проекта.
Меры предотвращения этому может послужить:
- четкое определение прав и обязанностей каждого участника;
- компетентность участников проектной группы со стороны заказчика;
- участие профессиональных консультантов;
- заблаговременное обучение рабочей группы и ключевых пользователей;
- своевременные разъяснительные работы для персонала заказчика;
- документирование технических условий и их согласование со всеми заинтересованными участниками проекта;
- обязательное утверждение любых изменений;
- утверждение технического задания, не содержащего избыточных характеристик.
Для стадии проектирования необходимой информационной системы по нашему мнению характерны такие риски, как:
- Риск ведения проекта;
- Риск неверного планирования;
- Стоимостной риск;
- Форс-мажор.
Основными факторами риска ведения проекта можно назвать следующие:
- неправильное определение рамок и масштабов проекта;
- проектирование ошибочных функций и интерфейсов будущей системы;
- не отлаженная система определения и управления рисками проекта
- выбор неправильных технологий и методов решения поставленных задач;
- несоблюдение требований заказчика при проектирование будущей системы или постоянное изменение требований.
В качестве мер предотвращения обозначенных выше моментом можно назвать:
- обеспечение стабильности границ проекта, определенных на начальном этапе, вплоть до окончания проекта;
- качественное планирование работ;
- своевременная идентификация проектных рисков и разработка рекомендаций по снижению рисков;
- обеспечение проекта необходимыми ресурсами;
- обязательное утверждение и согласование по проектным решениям;
- дополнительный анализ функций и целей проекта, более тщательная формулировка концепции, разработка руководств пользователя на ранней стадии, проведение опроса пользователей;
- установление достаточно высокого порога принятия изменений;
- использование методологии управления качеством для выявления неизвестных рисков проекта по ходу его выполнения.
Риск неверного планирования может возникнуть в следствие следующих обстоятельств:
- неэффективный организационный план внедрения системы на предприятии, то есть план работы проектной команды с учетом обязанностей, необходимых ресурсов и способов контроля результатов ее работы;
- срыв сроков выполнения работ по данному этапу в силу некомпетентности персонала исполнителя при проектировании.
Мерами предотвращения данных обстоятельств может служить следующее:
- укомплектование проектной команды наиболее талантливыми и квалифицированными проектировщиками;
- распределение работ соответственно способностям членов проектной команды;
- перекрестное обучение и контроль со стороны непосредственных руководителей;
- аудиты на ранних стадиях, конкурентное проектирование и прототипирование, организация командной работы, симуляция и моделирование;
- документирование всех работ на этапе проектирования и обеспечение доступности данных для всех участников проекта ;
- разработка системы поощрении и делегирование полномочий между участниками проекта;
- создание и обучение резервных людских ресурсов.
В качестве обстоятельств, способствующих возникновению стоимостного риска можно назвать:
- ошибочное планирование окупаемости системы;
- ошибочное планирование общей стоимости проекта;
- не получение оплаты заказчиком по завершении данного этапа (исключая случаи, относящиеся к непредвиденным ситуациям).
Мерами предотвращения этого является:
- детальная оценка стоимости с использованием нескольких источников;
- соотнесение сложности проектирования с его стоимостью;
- составления поэтапного плана выплат и определение штрафных санкций при задержке.
В качестве основного обстоятельства возникновения форс-мажорных ситуаций можно назвать аварии или отказы в работе аппаратного или программного обеспечения, используемого на этапе проектирования. Мерой предотвращения этому может послужить работа только надежное оборудование (Brand), а также наличие в штате квалифицированных технических специалистов, которые способны в минимальные сроки устранить неисправность.
Как нами уже было отмечено ранее, основным этапом жизненного цикла в рамках данного проекта выступает разработка самой АИС. При этом можно выделить следующие риски:
- Риск персонала и проектных коммуникаций;
- Технический и программный риски.
Основными факторами возникновения первого риска являются:
- зависимость от ключевого персонала;
- увольнение ключевых сотрудников, что повлечет за собой потери для проекта в виде знаний и информации, собранной данными сотрудниками;
- недопонимание между участниками проекта из-за отсутствия налаженной системы коммуникаций и поэтапного документирования работ;
- неправильное понимание задач проектирования программистами, в связи с чем неправильная реализация проекта;
- привлечение программистов без достаточного опыта работы с системами подобного класса.
Основными мерами предотвращения этого служит:
- тщательный отбор персонала, задействованного в данном проекте, обеспечение сертификации, а также организация контроля деятельности персонала их руководителями;
- разделение обязанностей, наличие резерва на выдвижение, обучение перспективных сотрудников, а также документирование накопленных знаний;
- налаженная система коммуникаций между сотрудниками проекта, подробное и четкое документирование требований и доступность проектной документации всем участникам рабочей группы.
Технический и программный риски могут породить:
- частичную или полную приостановку этапа разработки из-за ошибок в используемом программном обеспечение. Последствиями данного риска также может быть частичная или полная потеря созданной на данном этапе информации в виде кода программы.;
- контрольный пример не учитывает всех особенностей системы, то есть недостаточно проработан, что может привести к ошибкам на этапе эксплуатации системы;
- документация по системе не включает в себя подробного описания всего функционала системы, что в дальнейшем может привести к возникновению трудностей не этапе эксплуатации.
Этого можно избежать, учитывая:
- использование только проверенного лицензионного программного обеспечения, а также производить регулярное резервное копирование данных на альтернативные источники хранения данных;
- привлечение к тестированию опытных специалистов, многократные проверки и прогоны работоспособности системы для выявления малейших неисправностей в ходе работы;
- проверка документации перед передачей системы заказчику, контроль ее ведения и составления на протяжение всех этапов жизненного цикла ИС.
В процессе внедрения могут возникнуть такие риски, как:
- Риск персонала;
- Технический риск.
Факторами первого риска являются:
- увеличение нагрузки на персонал;
- несогласованность действий персонала исполнителя и сотрудников предметных областей;
- трудности с обучением персонала заказчика из-за нежелания работать с новой системой;
- отсутствие поддержки внедрения ИС со стороны отдельных ключевых участников проекта;
- неучастие руководителей высшего звена в проекте.
Этого можно избежать, путем реализации следующих идей:
- проведение обучения персонала заказчика работы с системой;
- составление плана внедрения ИС;
- доведение до персонала заказчика смысла внедрения автоматизированной системы;
- активное вовлечение высшего руководства в проект, активное взаимодействие с ним в ходе проекта и своевременное принятие решений, необходимых для нормальной реализации проекта.
Основными факторами технический риска являются следующие:
- потеря данных при внедрении ИС;
- возможный отказ технического оборудования при внедрении ИС.
Мерами предупреждения этого служит:
- привлечение квалифицированных технических специалистов, работающих ранее с проектами внедрения ИС, а также их активная работа с техническими специалистами исполнителя;
- использование пилотного, поэтапного - подхода к организации внедрения.
В процессе эксплуатации и сопровождения разработанной ИС могут возникнуть:
- Технические риски;
- Риски персонала.
Факторами технических рисков являются:
- ошибки в программе вызывающие простой системы;
- невозможность осуществления требуемых действия, «зависание» программы;
- использование вредоносных программ (вирусы, черви, трояны, логические бомбы), использование в корыстных целях найденных ошибок (дыр) в программах, перехват информации по телекоммуникациям, воровство информации;
- некорректная эксплуатация оборудования;
- приостановка деятельности третьего лица (например провайдера Интернет услуг), что повлечет за собой невозможность передачи отчетов из филиалов и контроля деятельности филиалов;
- несоответствие функциональных возможностей системы бизнес-процессам в комплекса задач в следствие реорганизационных изменений.
Предотвратить данные обстоятельства можно, соблюдая следующие моменты:
-тщательное тестирование и выявление ошибок на этапе разработки;
- устранять в кратчайшие сроки ошибки силами прошедших подготовку на этапе внедрения технических специалистов;
- администратор сети должен следить за безопасностью информации, использовать и вовремя обновлять антивирусные программы, правильно настроить FireWall, которые будут разделять локальную и внешнюю сеть, предоставить работникам организации возможность работы только с той информацией, которая им необходима для исполнения своих служебных обязанностей;
- разделение клиентского и серверного оборудования, а также необходимо привлечение обученного работе с системой квалифицированного персонала;
- наличие альтернативных средств доступа в Интернет или других способов передачи данных;
- документирование технических условий и их согласование со всеми заинтересованными участниками проекта;
- обязательное утверждение любых изменений.
Факторами возникновения риска персонала являются следующие обстоятельства:
- нарушение информационной безопасности работы - возможна утечка информации из-за злоумышленных действий сотрудников и не желании работать с новой системой;
- не определен этап выхода их проекта консультантов заказчика.
В противовес этому может выступать:
- организация системы поощрений использующего систему персонала заказчика;
- прием на работу сотрудников при условии не разглашения коммерческой тайны в противном случая - применение штрафных санкций;
- четкое планирование сроков проекта и момента прекращения работы над проектом со стороны исполнителя.
Таким образом, нам удалось определить основные риски, которые могут возникнуть на каждом из этапов жизненного цикла нашей информационной системы, определить факторы их возникновения, а также дать рекомендации по их предотвращению.
|
обратная связь
