Файл: Анализ и оценка средств реализации объектно-ориентированного подхода к проектированию экономической информационной системы (ТЕОРЕТИЧЕСКИЙ ОБЗОР ОСНОВНЫХ ПОНЯТИЙ И МЕТОДОВ ПРОЕКТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ).pdf

Рис. 2 пример реализации MDA архитектуры

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

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

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

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

ГЛАВА 2. ОБЪЕКТИВНО- ОРЕНТИРОВАННЫЕ МЕТОДОЛОГИИ РАЗРАБОТКИ ЭКОНОМИЧЕСКИХ ИНФОРМАЦИОННЫХ СИСТЕМ

2.1. Agile методология

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

---

Классическим вариантом организационной структуры проектно-ориентированной организации является функционально-матричная и ее разновидности (матричная, сбалансированная функционально-матричная, функциональную) [2]. С помощью матричной структуры успешно решаются проблемы управления отдельными проектами, но в случае портфелей проектов возникают качественно иные задачи [3, 4]:

- Установление приоритетов проектов - prioritization (для распределения ресурсов);

- Формирование эффективного портфеля - project selection (кроме экономической эффективности необходимо учитывать соответствие миссии, целям и стратегии компании)

- Формирование баланса между стратегическими и тактическими целями компании – balancing (Особенно важным это является для инновационных, IT-компаний, деятельность которых является исключительно проектно ориентированной)

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

Agile-менеджмент (от англ. Agile - «подвижный», «ловкий», «эластичный») – итерационный метод планирования и управления процессами и проектами, концентрируется на коротких циклах разработка, оперативных обновлениях в зависимости от изменения потребностей клиента и фокусируется на достижении персонального, технического и организационного успеха [5].

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

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

Agile- методы делают акцент на непосредственное общение. Большинство agile- команд расположено в одном офисе, иногда так называемом англ. bullpen. Как минимум, она включает и «Заказчиков» (англ. Product owner - заказчик или его полномочный представитель, определяет требования к продукту; это роль может выполнять менеджер проекта, бизнес - аналитик или клиент). Офис может также включать тестировщиков, дизайнеров интерфейса, кодировщиков и менеджеров.

---

Основной метрикой agile - методов является рабочий продукт. Отдавая предпочтение непосредственному общению, agile - методы уменьшают об Объем письменной документации, по сравнению с другими методами. Это привело к критике этих метод и в, как «недисциплинированных».

Основные принципы методологии:

удовлетворение клиента за счет ранней и своевременной поставки программного обеспечения;

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

частая поставка рабочего программного обеспечения (каждый месяц или неделю или еще чаще)

тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;

проектом занимаются мотивированы личности, которые обеспечены нужными условиями работы, поддержкой и доверием;

рекомендован метод передачи информации - личная беседа;

работающее программное обеспечение - лучший измеритель прогресса;

постоянное внимание улучшению технического мастерства и удобному дизайну;

простота - искусство НЕ делать лишней работы;

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

постоянная адаптация к меняющимся обстоятельствам.

Agile - семейство процессов разработки, а не единый подход в разработке программного обеспечения, и определяется Agile Manifesto [8].

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

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

Далее приведены некоторые из методологий, отвечающих принципам Agil e. Agile Modeling - набор понятий, принципов и приемов ( практик ), что позволяют быстро и просто выполнять моделирование и документирование в проектах разработки программного обеспечения. Не включает в себя подробную инструкцию по проектированию, не содержит описаний, я к строить диаграммы на UML. Основная цель: эффективное моделирование и документирование; но не охватывает программирования и тестирования, не включает вопросы управления проектом, развертывание и сопровождения системы. Однако включает в себя проверку модели кодом.

---

Agile Unif ied Process (AUP) - упрощенная версия IBM Rational Unified Process (RUP), разработанная Скоттом Амблер , которая описывает простое и зрозуміле наближення ( модель ) для створення програмного забезпечення для прикладних програм .

Dynamic Systems Development Method (DSDM) основан на концепции быстрой разработки приложений (Rapid Application Development, RAD).

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

2.1. Экстремальное программирование.

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

Экстремальное программирование (англ. Extreme programming, XP)

методология разработки программного обеспечения, популярная среди быстрых методологий.

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

Короткий цикл обратной связи (Fine scale feedback):

Разработка через тестирование (Test driven development)

Игра в планирование (Planning game);

Заказчик всегда рядом (Whole team, Onsite customer);

Парное программирование (Pair programming)

Непрерывный, а не пакетный процесс:

Непрерывная интеграция (Continuous Integration)

Рефакторинг (Design Improvement, Refactor)

Частые небольшие релизы (Small Releases);

Понимание, что делится всеми участниками:

Простота (Simple design);

Метафора системы (System metaphor);

Коллективное владение кодом (Collective code ownership) или выбранным шаблонам проектирования (Collective patterns ownership)

Стандарт кодирования (Coding standard or Coding conventions)

Социальная защищенность программиста (Programmer welfare):

40 часовая рабочая неделя (Sustainable pace, Forty hour week).

XP особое внимание уделяется двум разновидностям тестирования:

---

тестирования модулей (unit testing)

приемное тестирование (acceptance testing).

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

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

Для XP более приоритетным является подход, называемый TDD (Test Driven Development) - сначала пишется тест, который не проходит, потом пишется код, чтобы тест прошел, а уже после цо го делается рефакторинг кода.

«Заказчик» в XP - это конечный пользователь программного продукта . Заказчик должен быть все время на связи и доступен для вопросов.

парное программирование

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

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

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

Рефакторинг (refactoring) - это методика улучшения кода, без изменения его функциональности. XP предусматривает, что однажды написанный код в процессе работы над проектом будет неоднократно переработан. Этот процесс называется рефакторингом.

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

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

---