Технологии системного проектирования программных средств

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

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

· тип используемых программно-инструментальных средств;

· сложность решаемой задачи.

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

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

Необходимая для решения задачи входная информация может быть представлена в виде первичных документов как ручного, так и машинного заполнения, содержимого баз данных (в компьютере и на носителях информации), приходящих по каналам связи сообщений. При их описании конкретизируется тип каждого используемого реквизита (числовой, символьный, дата и др.) и его разрядность (достаточная для ввода потенциально самого “длинного” значения); необходимая точность описания реквизита (посредством задания числа десятичных знаков после запятой); возможный диапазон изменения значений реквизитов. Аналогичная информация задается и для выходных результатов.

Рис. 5.2. Обобщенная схема процесса разработки приложения

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

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

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

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

В целом при разработке экономико-математической модели и определении метода решения задачи часто используют несколько классов моделей:

· аналитические (вычислительные);

· матричные (балансовые);

· графические и др.

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

· возможность обеспечения решения задачи с заданной точностью при любых возможных значениях входных данных;

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

· время решения задачи;

· стоимость приобретения, при необходимости, программных средств.

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

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

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

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

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

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

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

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

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

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

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

· формирование требований к программному обеспечению;

· проектирование;

· реализацию;

· тестирование;

· ввод в действие;

· эксплуатацию и сопровождение;

· снятие с эксплуатации.

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

При проектировании современных экономических информационных систем основная доля трудозатрат приходится на разработку прикладного программного обеспечения и баз данных. Еще в 70-х годах в США возник кризис программирования, проявившийся в том, что большие проекты стали выполняться со значительным отставанием от запланированных сроков разработки и/или с заметным превышением сметы расходов. Во многих случаях не удавалось обеспечить требуемые функциональные возможности и уровень производительности при эксплуатации программного продукта.

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

Необходимость контроля процесса создания программного обеспечения, гарантированной оценки стоимости разработки и сроков ее выполнения, обеспечения требуемых функциональных возможностей обусловили объективную потребность перехода к индустриальным способам создания ПО. Соответствующее направление создания ПО получило название программная инженерия (software engineering). В процессе его становления и развития явно выделяются два этапа: период 70-80-х годов, когда систематизация и стандартизация процессов создания ПО осуществлялась на основе структурного подхода; период 90-х годов, во время которого начался переход к сборочному способу создания ПО на основе объектно-ориентированного, а затем и визуально-ориентированного подходов. Основой реализации второго этапа явилось резкое увеличение производительности средств вычислительной техники и массовое распространение компьютерных сетей.

Для современных крупных проектов в области экономических информационных систем, как правило, характерны следующие особенности:

· сложность описания систем ввиду большого количества процессов, элементов данных и взаимосвязей между ними;

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

· необходимость интеграции с ранее разработанными и используемыми приложениями;

· отсутствие полных аналогов, что даже в простейших случаях предполагает “привязку” типового решения к реальным условиям;

· необходимость совмещения в системе регламентных (периодически решаемых) и не регламентных (разовые запросы произвольной формы) задач;

· функционирование разрабатываемого программного обеспечения в среде с разнотипными средствами вычислительной техники;

· длительный период проектирования и внедрения результатов в связи со сложностью задач и различной степенью готовности отдельных структурных подразделений организации-заказчика к внедрению и др.

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

Адекватные модели служат основой взаимодействия всех участников проекта и в значительной степени гарантируют корректность архитектуры. Важная роль в процессе реализации проекта отводится языку моделирования, который содержит в своем составе элементы модели - базовые концепции моделирования и их семантику, нотацию - визуальное представление элементов моделирования, руководство по использованию – правила применения элементов в рамках построения тех или иных типов моделей программного обеспечения. Нотация представляет собой совокупность графических объектов, которые используются в моделях; она является синтаксисом языка моделирования. Большинство существующих методов объектно-ориентированного анализа и проектирования включает в себя как язык моделирования, так и описания процесса моделирования. Язык моделирования – это нотация (в основном графическая), которая используется методом для описания проектов. Необходимо отметить, что в отличие от широко трактуемого понимания сущности моделирования, конечной целью разработки ПО является создание эффективно работающих приложений (написание совокупности взаимодействующих программ), поэтому языки моделирования являются инструментом построения наглядных графических моделей, описывающих различные аспекты архитектуры ПО (как статическую структуру, так и динамику поведения системы).

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

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

Одним из базовых понятий программной инженерии является понятие жизненного цикла программного обеспечения, определяемого как период времени, начинающийся с момента принятия решения о необходимости создания ПО и заканчивающийся в момент его полного изъятия из эксплуатации. Состав процессов, формирующих жизненный цикл ПО, регламентируется международным стандартом ISO/IEC 12207:1995 “Information Technology – Software Life Cycle Processes” (ISO – International Organization for Standardization – Международная организация по стандартизации, IEC – International Electrotechnical Commission – Международная комиссия по электротехнике). Стандарт определяет структуру жизненного цикла, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО. Понятие программного продукта в нем определено как набор компьютерных программ, процедур и, возможно, связанной с ним документации и данных. Положения стандарта являются общими для любых моделей жизненного цикла, методов и технологий разработки ПО, однако они не конкретизируют особенности реализации процессов.

В состав жизненного цикла ПО обычно включают следующие этапы:

· формирование требований к программному обеспечению;

· проектирование и тестирование;

· ввод в действие;

· эксплуатацию и сопровождение;

· снятие с эксплуатации.

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

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

· проведение обследования деятельности автоматизируемого объекта: определение структуры организации и ее целевых функций, анализ распределения функций по подразделениям и конкретным сотрудникам, выявление характера взаимодействий между подразделениями, анализ используемых средств автоматизации деятельности организации и др.;

· построение модели “AS–IS” (“как есть”), отражающей существующие на момент обследования особенности функционирования организации и выявление “узких мест”, а также модели “ТО–ВЕ” (“как должно быть”), отражающей представления о новых технологиях работы организации. Переход от модели “AS–IS” к модели “ТО–ВЕ” может быть выполнен как на основе совершенствования существующих технологий (инжиниринг бизнес-процессов), так и через радикальное изменение технологий и перепроектирование бизнес-процессов (реинжиниринг бизнес-процессов);

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

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

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

Процесс разработки включает в себя следующие действия:

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

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

· кодирование и тестирование ПО: разработка (кодирование) и документирование каждого компонента ПО и базы данных, а также всех тестовых процедур и данных для всестороннего тестирования каждого компонента ПО; собственно тестирование каждого компонента ПО на соответствие предъявляемым требованиям с документированием результатов; обновление при необходимости пользовательской документации; обновление плана интеграции ПО;

· интеграция ПО, предполагающая сборку разработанных компонентов в соответствии с планом интеграции в более крупные компоненты и тестирование сформированных агрегированных компонентов. Интеграция компонент ПО в единое целое и тестирование системы в целом;

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

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

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

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

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

При проектировании прикладного программного обеспечения широко используются две модели жизненного цикла ПО: каскадная (более ранняя) и спиральная (современная).

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

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

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

В 90-х годах при разработке прикладного ПО в рамках спиральной модели широкое применение находит способ быстрой разработки приложений – RAD. Его применение предполагает наличие трех составляющих:

· ряда групп разработчиков из нескольких специалистов, способных совместно проектировать отдельные подсистемы ПО;

· тщательно проработанного графика выполнения работ (обычно до 3 месяцев);

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

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

В соответствии с подходом RAD основу жизненного цикла продукта составляют три этапа:

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

· проектирование (собственно разработка);

· внедрение.

На первом этапе определяются:

· выполняемые системой функции и среди них выделяются приоритетные функции, требующие первоочередной проработки;

· информационные потребности к будущей системе (здесь существенную помощь заказчикам оказывают разработчики);

· временные рамки каждой из итераций и анализируется возможность реализации проекта в целом (при заданном объеме финансирования, на указанных заказчиком аппаратных средствах и др.);

· разрабатываются предварительные (самые общие) модели ПО.

На втором этапе выполняются следующие действия:

· детально рассматриваются все процессы системы, для каждого из них определяется возможный прототип (экранная форма, отчет, взаимодействие в режиме диалога и др.);

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

· определяются интересы взаимодействия между автономно разрабатываемыми подсистемами и логические структуры для обмена данными (файлы, документы, экранные формы и др.);

· определяются процедуры, реализующие разграничение доступа к данным;

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

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

· анализируются и реализуются возможности повышения производительности системы в целом;

· подготавливается техническая и сопроводительная документация.

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

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

Преимущества подхода RAD ощутимы при разработке проектов средней сложности в рамках хорошо отлаженной среды разработки с многократным использованием готовых (библиотечных) компонент при малых сроках на выполнение проектов.

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

Контекст технологической операции образуют:

· исходные данные в стандартном представлении (документы, результаты предыдущих операций и др.);

· методологические материалы, инструкции, нормативы и стандарты, критерии оценки результатов;

· исполнители;

· инструментальные средства;

· результаты в стандартном исполнении.

Современные технологии проектирования ПО для экономических информационных систем должны обеспечивать:

· соответствие международному стандарту ISO/IEC 12207;

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

· независимость полученных проектных решений от средств реализации (СУБД, ОС, языков и систем программирования);

· поддержка проектирования комплексом согласованных CASE-средств, обеспечивающих автоматизацию процессов на всех этапах жизненного цикла ПО.

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

· стандарт проектирования, устанавливающий: набор необходимых моделей (диаграмм) на каждой стадии проектирования и степень их детализации; правила отражения проектных решений на диаграммах; требования к конфигурации рабочих мест проектировщиков, включая настройки ОС, CASE-средств и др.; процедуры обеспечения совместной работы над проектом (регламент обмена проектной информацией, правила интеграции результатов, правила анализа проектных решений на непротиворечивость и др.);

· стандарт оформления проектной документации, определяющий: комплектность, состав и структуру документации на каждой стадии проектирования (в соответствии со стандартом ГОСТ Р ИСО 9127-94 “Системы обработки информации. Документация пользователя и информация на упаковке потребительских программных пакетов”); требования к оформлению документации (включая требования к содержанию разделов, подразделов, пунктов и др.); правила подготовки, рассмотрения, согласования и утверждения документации с указанием предельных сроков для каждой стадии; требования к настройкам средств автоматизации, обеспечивающих подготовку документации (в том числе, CASE-средств, издательских систем и др.);

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

Помимо основных процессов (разработка, эксплуатация и сопровождение ПО), стандарт ISO/IEC 12207 определяет также группы вспомогательных и организационных процессов, в рамках модели жизненного цикла ПО.

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

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

Создание эксплуатационной документации на программный продукт предполагает формирование:

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

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

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

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

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

Дата добавления: 2014-01-13