close

Вход

Забыли?

вход по аккаунту

Выбор методологии разработки программного обеспечения для

код для вставкиСкачать
Критерій скінченності  -типу аналітичних в проколеній площині функцій [Текст] / І.П. Кшановський // Вісник Національного технічного університету "ХПІ". Серія: нові рішення в сучасних технологіях. − 2013. − № 4(978). − С. 164-171. 7. Хейман, У. К. Мероморфные функции [Текст] / У.К. Хейман – М: Мир, 1966. – 287 C.
УДК: 517.53
Про мажоранти зростання аналітичних в проколеній площині функцій/ І. П. Кшановський, Г. В. Івасик // Вісник НТУ «ХПІ». Серія: Нові рішення в сучасних технологіях. – Х: НТУ
«ХПІ», – 2014. - № 7 (1050). – С.76-84 . – Бібліогр.: 7 назв. ISSN 2079-5459
Найдены лучшие в некотором смысле мажоранты роста двопараметрической характеристики
аналитической в проколотой плоскости функции с заданым ограничением на количество ее нулей.
Ключевые слова: аналитическая функция, двусвязная область, характеристика Неванлинны,
функция роста.
On the growth majorant of analytic functions in a punctured plane/ I. Kshanovskyy, G. Ivasyk
//Bulletin of NTU “KhPI”. Series: New desicions of modern technologies. – Kharkov: NTU “KhPI”, 2014.№ 7 (1050).- P.76-84. Bibliogr.:7. ISSN 2079-5459
We find the best in a certain sense growth majorant of two-parametric characteristic of analytic
functions with given constraints on the number of its zeros in the punctured plane.
Keywords: analytic function, doubly connected domain, Nevanlinna characteristic, growth
function.
УДК 65.011.56
Е. П. ПАВЛЕНКО, канд. техн. наук, доц., ХНУРЭ, Харьков;
И. А. КРИВОРОТЕНКО, студент, ХНУРЭ, Харьков;
В. А. АЙВАЗОВ, ст. препод., ХНУРЭ, Харьков
ВЫБОР МЕТОДОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО
ОБЕСПЕЧЕНИЯ ДЛЯ СТРАХОВОЙ КОМПАНИИ
Рассмотрена проблема выбора методологии разработки программного обеспечения информационных
систем. Были исследованы и проанализированы проблемы классических методологий разработки.
Также была рассмотрена гибкая методология разработки как альтернатива классическому подходу.
Ключевые слова: методология разработки, Спиральная модель, Каскадная модель, Agile методологии.
Введение. Повсеместно во многих организациях созданы и эффективно действуют
информационные системы (ИС), обслуживающие процесс подготовки и принятия управленческих решений и решающие следующие задачи: обработка данных, обработка информации, реализация интеллектуальной деятельности.
Информационная система предприятия представляет собой совокупность информационных процессов, выполняющихся для удовлетворения потребности в информации на разных уровнях принятия решений. Информационная система состоит из компонентов обработки информации, различных задач и подсистем. Информационные системы реализуют принципы единства информационногопроцесса, информации и организации путем
применения технических средств процессов сбора, накопления, обработки и передачи
информации.
Программное обеспечение (ПО) – важнейший вид обеспечения информационной
системы, обеспечивающий практическую реализацию процессов обработки информации.
На разработку программного обеспечения затрачивается большая часть средств,
© Е. П. ПАВЛЕНКО, И. А. КРИВОРОТЕНКО, В. А. АЙВАЗОВ, 2014
ISSN 2079.5459. Вісник НТУ “ХПІ». 2014. № 7 (1050)
84
выделенных на проектирование информационной системы в целом. В связи с этим важно
обеспечить применение эффективной методологии разработки программного продукта.
Компания «Мамина забота» (г.Харьков) занимается продажей страховых полисов
для групп физических лиц. На данном этапе компания имеет большую популярность и
работает с большим количеством заказов. В связи с этим возникает необходимость в автоматизации процесса продажи полисов. Разработанное приложение позволит пользователям Интернет самостоятельно предоставлять все необходимые данные для страхования
и осуществлять покупку страхового полиса.
Проблемы, с которыми пришлось столкнуться при разработке программного обеспечения ИС данной страховой компании, взаимосвязаны: аналитику сложно получить
исчерпывающую информацию для оценки требований к ПО с точки зрения заказчика; заказчик не знает, какие процессы обработки будут выполнены, какие нет; аналитику трудно оценить проблемы предметной области; спецификация на ПО из-за технических терминов непонятна заказчику.
Цель работы. Целью работы является исследование и выбор методологии разработки программного обеспечения для ИС страховой компании
Постановка задачи. Программное обеспечение, разрабатываемое для страховой
компании, характеризуется: сложностью структуры из-за наличия большого числа элементов и связей; быстрым изменением функций и целей создания программной системы;
расширением степени автоматизации учетных функций. В связи с этим программная система должна быть развивающейся и непрерывно модернизируемой без коренной перестройки ее структуры.
На протяжении всего жизненного цикла разработки программного продукта необходимо осуществлять контроль своевременности и качества разработки. От результатов
выполнения каждого этапа зависит общий успех программного проекта. Эффективное
построение процесса разработки программного продукта позволит снизить риски к минимуму, а также максимально учесть требования заказчика.
В связи с этим необходимо произвести выбор методологии разработки программного продукта, который учитывал бы особенности ИС страховой компании.
Основные методологии, используемые при разработке программного обеспечения информационных систем. Существует множество современных методологий разработки программного обеспечения. Однако существующие методологии не являются
универсальными и имеют применение лишь в проектах определенного типа.
Существующие подходы разработки программного обеспечения включают в себя
методы, основанные на этих моделях жизненного цикла разработки ПО:
- каскадная;
- спиральная;
- инкрементная.
Этапы разработки классической каскадной модели выглядят следующим
образом: анализ требований к программному продукту; проектирование продукта; реализация ПО; тестирование ПО; интеграция программной системы; поддержка ПО.
Переход на следующий этап возможен только после полного окончания работ предыдущего этапа. Результатом каждого этапа жизненного цикла является полный комплект документации. Это позволяет стандартизовать процесс разработки ПО.
Преимуществами каскадной модели являются последовательное выполнение этапов
программного проекта, а также возможность оценки качества программного продукта на
каждом этапе.
Недостатки - отсутствие обратной связи между этапами, а также задержка получения результатов. Сравнение результатов с требованиями заказчика проводится только
после завершения определенных этапов, что не дает возможности вносить коррективы во
85
ISSN 2079.5459. Вісник НТУ “ХПІ». 2014. № 7 (1050)
время выполнения этапа. Кроме того, каскадная модель недостаточно гибка, программные проекты, разрабатываемые по этой модели, имеют стоимость и время разработки
больше, чем в случае применения других моделей.
Спиральная модель разработки программного обеспечения основана на проектировании и создании прототипов. Особенность модели - повышенное внимание уделяется
начальным этапам процесса разработки - анализу и проектированию. Виток спирали - это
завершенный процесс по созданию определенной части программного продукта.
Преимущества спиральной модели: более быстрое, чем в каскадной модели, получение результата, а также возможность изменять требования во время выполнения этапов
разработки ПО.
Недостаток - сложность определения момента перехода на следующий этап. Вводятся временные ограничения на каждом витке спирали. Переход осуществляется в соответствии с планом, даже если не все запланированные работы завершены. План составляется
на основе статистических данных, полученных в предыдущих проектах.
Инкрементная модель разработки ПО состоит в реализации программной системы
по частям и постепенного наращивания функциональных возможностей. Это позволяет
уменьшить затраты, понесенные до достижения необходимой производительности. Применяется принцип компоновки программной системы из стандартных блоков – функций
и классов, благодаря чему обеспечивается учет изменяющихся при разработке требований.
Преимущество инкрементной модели состоят в том, что отпадает необходимость заранее вкладывать средства, выделенные на весь проект, поскольку сначала разрабатываются лишь часть функций системы. Нет необходимости в формировании громоздких перечней требований, упрощается тестирование программной системы по сравнению с
продуктами, разработанными по спиральной или каскадной модели.
Существенный недостаток инкрементной модели: поскольку создание некоторых
модулей будет завершено раньше других, возникает необходимость в четко определенных интерфейсах и «заглушках». Инкрементная модель применяется в основном в случаях, если необходимо быстро поставить на рынок программный продукт, имеющий функциональные базовые свойства.
Таким образом, актуальной проблемой является метод построения усовершенствования управления процессом создания программных средств, которые могут повысить
эффективность процесса разработки ПО вменяющихся требований. Для устранения недостатков этих методологий применяются гибкие методологии разработки программных
продуктов.
Применение гибких методологий при разработке программных продуктов
Традиционный подход к управлению проектами является линейным, где все делается в одном цикле. Все подробно планируется, и по результатам выполнения всех этапов
жизненного цикла проект сдается целиком, и это - основное отличие традиционного
подхода от гибкого, или Agile-подхода. В настоящее время методология Agile достаточно
популярна и предлагает эффективные пути решения многих проблем, существующих в
проектах разработки программных продуктов.
При использовании гибкой методологии разработки планируется только лишь некоторый ограниченный функционал. После завершения этапа разработки заказчик может
видеть работающую версию программного продукта, а также оценить, в правильном ли
направлении он движется. Это позволяет заказчику определить новые либо переопределить существующие требования. Такой подход к разработке предусматривает возможные
изменения в требованиях заказчика и позволяет применить эти изменения во время разработки проекта.
ISSN 2079.5459. Вісник НТУ “ХПІ». 2014. № 7 (1050)
86
В условиях постоянного изменения страхового законодательства существуют риски
того, что требования к разрабатываемому программному продукту будут изменяться. Поэтому целесообразно при разработке продукта применить гибкую методологию, которая
позволяет своевременно и эффективно вносить изменения в проект в соответствии с новыми требованиями. Также использование гибкой методологии разработки дает возможность выявить и устранить отклонения от желаемого результата на ранних этапах разработки продукта за счет постоянной верификации продукта заказчиком.
Большинство гибких методологий направлены на сведение риска к минимуму путем
уменьшения итераций – коротких отрезков времени, которые обычно длятся
одну-две недели. Каждая итерация выглядит
как сокращённый жизненный цикл разработки и включает в себя все задачи: планирование, анализ требований, проектирование, кодирование, тестирование и документирование. Несмотря на то, что результатов работы
отельной итерации недостаточно для выпуска новой версии продукта, каждая итерация
на выходе имеет работающий продукт с реализованным функционалом, запланированным заранее. Заказчики могут видеть результат разработки на протяжении всего жизненного цикла проекта. Методология иллюстриРис. 1 – Жизненный цикл проекта с исруется на рис. 1.
пользованием
гибкой модели разработки
Сотрудничество между заказчиком и
разработчиками испытывает трудности
в понимании требований к программному продукту. Основная цель заказчика – достичь
того, чтобы программная система работала без сбоев, ошибок, и была удобной и простой
в использовании. После разработки по классической методологии эти цели могут быть не
достигнуты.
Выводы. Внедрение гибкой методологии разработки программной системы позволяет сконцентрироваться преимуществах каждого элемента в разработке, при этом очень
важным является момент взаимодействия с заказчиком. Заказчик может видеть результат
разработки на протяжении всего жизненного цикла проекта и соответственно вносить
коррективы.
Классический подход, как правило, является наилучшим вариантом для больших
статичных проектов, где заказчик твердо уверен в своих требованиях и заранее представляет как должен выглядеть разрабатываемый продукт. В противоположность этому, гибкие методологии разработки будут более приемлемым вариантом для проектов, где изменения могут быть сделаны в процессе проектирования – в частности, при разработке ПО
для ИС страховой компании.
Список литературы: 1. Kniberg H. Scrum and XP from the Trenches [Текст] / H. Kniberg – Williams,
2010.– 268 с. 2. Книберг Х. Scrum и XP: заметки с передовой. [Текст] / Х. Книберг – Williams,
2011.– 266 с. 3. Мартин Р. Быстрая разработка программ. Принципы, примеры, практика. [Текст] / P.
Мартин – Tennessy, 2011.– 264 с.
Поступила в редколлегию 20.01.2014
УДК 65.011.56
Выбор методологии разработки программного обеспечения для страховой компании/ Павленко Е. П., Криворотенко И. А., Айвазов В. А. // Вісник НТУ «ХПІ». Серія: Нові рішення в су-
87
ISSN 2079.5459. Вісник НТУ “ХПІ». 2014. № 7 (1050)
часних технологіях. – Х: НТУ «ХПІ», – 2014. - № 7 (1050). – С.84-88 . – Бібліогр.: 3 назв. ISSN 20795459
Розглянуто проблему вибору методології розробки програмного забезпечення інформаційних
систем. Були досліджені і проаналізовані проблеми класичних методологій розробки. Також була
розглянута гнучка методологія розробки як альтернатива класичному підходу.
Ключові слова: методологія розробки, Спіральна модель, Каскадна модель, Agile методології.
Choice of methodology of software development for insurance company/ E. P. Pavlenko, I. A.
Krivorotenko, V. A. Ayvazov //Bulletin of NTU “KhPI”. Series: New desicions of modern technologies. –
Kharkov: NTU “KhPI”, 2014.-№ 7 (1050).- P.84-88. Bibliogr.:3. ISSN 2079-5459
It was considered the choice of methodology for information systems problem. It was investigated and
analyzed the problems of the classical development methodologies. It was also considered a flexible development methodology as an alternative to the classical approach.
Keywords: development methodology, Waterfall model, Cascade Model, Agile methodology.
УДК 656
А. О. ЛОБАШОВ, д-р техн. наук, проф., ХНАГХ, Харьков
МОДЕЛИРОВАНИЕ ФУНКЦИОНИРОВАНИЯ ТРАНСПОРТНОЙ
СЕТИ ПОСЛЕ ИЗМЕНЕНИЯ ЕЕ ПАРАМЕТРОВ
Представлен подход к моделированию транспортных потоков, позволяющий оценить результаты мероприятий по совершенствованию транспортной сети города.
Ключевые слова: транспортная сеть, транспортные потоки, интенсивность движения, уровень
автомобилизации.
Введение Транспортная сеть наземных видов транспорта является основной подсистемой всей транспортной системы города. Именно в рамках этой подсистемы осуществляется более 95% всех городских перевозок. Поэтому функционирования транспортных
сетей крупнейших городов в значительной степени определяет выполнение требований
эффективности, безопасности и комфортабельности ко всей транспортной системе. Обеспечить снижение уровня загрузки дорог движением в городах могут различные методы организации дорожного движения. Однако при этом возникает необходимость предварительной
оценки эффективности проводимых мероприятий.
Цель работы. Цель работы заключается в разработки модели функционирования
действующей транспортной сети города, которая дает возможность производить предварительную оценку мероприятий, связанных с изменением параметров транспортной сети.
Анализ последних исследований и публикаций. Моделированию транспортных
потоков посвящено достаточно много работ [1-8]. Для решения этой задачи применяются
различные подходы. Разработанные модели характеризуются различной сложностью и
точностью. Это связано с трудностями при решении задачи распределения транспортных
потоков по сети [1, 2]. При этом на параметры распределения влияют следующие факторы [2, 6]:
- характеристики внешних транспортных связей;
- параметры сети парковки автомобилей в транспортной сети города;
- особенности транспортно-планировочной структуры города;
- строительство новых жилых микрорайонов или крупных узлов транспортного тяготения;
- наличие ограничений на выполнение маневров на пересечениях транспортной сети;
© А. О. ЛОБАШОВ, 2014
ISSN 2079.5459. Вісник НТУ “ХПІ». 2014. № 7 (1050)
88
1/--страниц
Пожаловаться на содержимое документа