Основные этапы создания программных средств и изделий (продуктов), входящих в состав ПО АИС.

 

Жизненный цикл программного средства и изделия (продукта):

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

§ снятие программного изделия (продукта) с продажи, отказ от сопровождения.

Маркетинг и спецификация программного изделия (продукта) включает:

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

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

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

- установление требований к комплексу технических и программных средств для эксплуатации программного продукта и т.д.;

- составление задания на разработку программного изделия (продукта).

Проектирование структуры ПС в составе программного изделия (продукта):

- детализацией функций обработки отдельными модулями;

- разработка структуры программного продукта (архитектуры программных модулей, извзаимосвязей);

- разработка структуры информационной базы (базы данных);

- выбор методов и средств создания программ - технологии программирования.

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

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

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

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

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

Требуется постоянная программа маркетинговых мероприятий и поддержки программных продуктов. Как правило, для каждого программного продукта существует своя форма кривой продаж, которая отражает спрос.

Вначале продажа программного продукта идет вверх — возрастающий участок кривой. Затем наступает стабилизация продаж программного продукта. Фирма-разработчик стремится к максимальной длительности периода стабильных продаж на высоком уровне.

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

Эксплуатация программного продукта идет параллельно с его сопровождением, при этом эксплуатация программ может начинаться и в случае отсутствия сопровождения или продолжаться в случае завершения сопровождения еще какое-то время.

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

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

Длительность жизненного цикла для различных программных продуктов неодинакова. Для большинства современных программных продуктов длительность жизненного цикла измеряется в годах (2-3 года). Хотя достаточно часто встречаются на компьютерах и давно снятые с производства программные продукты.

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

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

 

 

 

Основным недостатком каскадного подхода является существенное запаздывание с получением ре­зультатов. Согласование результатов с пользователями производится только в точках, планируемых после завершения каждого этапа работ, требования к ПО "заморожены" в виде технического задания на все время ее создания. Таким образом, пользователи могут внести свои замечания только после того, как работа над системой будет полностью завершена. В случае неточного изложения требова­ний или их изменения в течение длительного периода создания ПО, пользователи получают систему, не удовлетворяющую их потребностям. По некоторым статистическим оценкам, сделанным на ос­нове опыта разработок АСУ прошлых лет, по указанной причине переделывалось до 60-70% ПО АС.

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

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

Одним из возможных подходов к разработке ПО в рамках спиральной модели ЖЦ является полу­чившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается подход к разработке ПО, определяемый следующими условиями: небольшая команда программистов (от 2 до 10 человек); короткий, но тщательно проработанный производственный график (от 2 до 6 мес.); повторяющийся цикл, при котором разработчики, по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказ­чиком.

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

Жизненный цикл ПО по концепции RAD состоит из четырех фаз: анализ и планирование требований; проектирование; построение; внедрение.

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

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

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

С использованием CASE-средств проект распределяется между различными командами (делится функциональная модель). Результатом данной фазы должны быть:

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

Все модели и прототипы должны быть получены с применением тех CASE-средств, которые будут использоваться в дальнейшем при построении системы. Данное требование вызвано тем, что в тра­диционном подходе при передаче информации о проекте с этапа на этап может произойти фактиче­ски неконтролируемое искажение данных. Применение единой среды хранения информации о про­екте позволяет избежать этой опасности.

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

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

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

Завершается физическое проектирование системы: определяется необходимость распределения данных; производится анализ использования данных; производится физическое проектирование базы данных; определяются требования к аппаратным ресурсам; определяются способы увеличения производительности; завершается разработка документации проекта.

Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.

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

Следует отметить, что методология RAD не может претендовать на универсальность, она хороша в первую очередь для относительно небольших проектов, разрабатываемых для конкретного заказчика. Она неприменима при разработке типовых систем, представляющих собой комплекс типовых компо­нент, адаптируемых к различным программно-техническим платформам, СУБД, средствам телеком­муникации, организационно-экономическим особенностям объектов внедрения и интегрируемых с существующими разработками. Для таких проектов необходимы высокий уровень планирования и жесткая дисциплина проектирования, строгое следование заранее разработанным протоколам и ин­терфейсам, что снижает скорость разработки.

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

 

⇐ Предыдущая12345Следующая ⇒

Поделиться:

Воспользуйтесь поиском по сайту: