Преподаватель который помогает студентам и школьникам в учёбе.

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

Содержание:

ВВЕДЕНИЕ

Разработка программного обеспечения (ПО) является относительно молодой отраслью инженерных работ, которая начала активно развиваться в конце прошлого века [1]. Поэтому естественно, что ранние подходы к разработке программных продуктов были мало формализованными и базировались на принципе Code-and-Fix (кодирование и исправление) [2]. Дальнейшее развитие методов и средств программирования обусловило формализацию подходов к созданию программных ресурсов с целью увеличения эффективности процессов программирования.

В теории инженерии программного обеспечения наукой накоплен значительный теоретический материал и практический опыт, причем весомый вклад в развитие моделей и методов разработки программного обеспечения сделали отечественные и зарубежные ученые, среди которых Буч Г., Вендров А.М., Jacobson I., Wil van der Aalst, Иан Соммервил, Scheer AW, Schill A., Самуйлов К.Е., Теленик С.Ф., Петренко А.В., Глоба Л.С. и др.

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

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

архитектурой [2]. Такой подход позволил повысить эффективность работы программистов и увеличить надежность разработанных программ [3].

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

Целью работы является обзор методов «быстрой» разработки программной системы.

Объектом исследования возникают процессы создания программного обеспечения.

Под предметом исследования понимаем agile-методы и методы экстремального программирования.

Главными задачами работы видим:

анализ литературы по избранной теме

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

проведение вариантного анализа методов «быстрой» разработки программной системы.

ГЛАВА 1.ТЕОРЕТИЧЕСКИЙ ОБЗОР ОСНОВНЫХ ПОНЯТИЙ И МЕТОДОВ ПРОЕКТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

1.1.Сущность проектирования программного обеспечения

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

Эталонную модель программной инженерии можно определить как взаимодействие трех факторов:

 процессов;

 продуктов;

 ресурсов.

Каждая программная система на протяжении своего существования проходит с определенной последовательностью фазы или стадии от замысла до его воплощения в программы, эксплуатацию и изъятия. Такая последовательность фаз называется жизненным циклом разработки (Software life cycle processes). На каждой фазе происходит определенная совокупность процессов, каждый из которых порождает определенный продукт, используя определенные ресурсы.

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

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

Виды деятельности, которые составляют процессы жизненного цикла программной системы, зафиксировано в международном стандарте ISO / IEC 12207: 1995-0801: Informational Technology - Software life cycle processes [1].

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

 главные процессы;

 вспомогательные процессы;

 организационные процессы.

К главным процессам отнесены следующие:

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

 процесс разработки, который означает действия организации – разработчика программного продукта;

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

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

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

В свою очередь, в процесс разработки входят следующие процессы:

 инженерия требований к системе;

 проектирования;

 кодирования и тестирования.

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

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

Стандарт, рассмотренный нами выше, является главным фактором определения содержания деятельности в сфере программной инженерии, и все знания, в которых нуждаются профессионалы с программной инженерии, формулируются относительно процессов, определенных стандартом ISO / IEC 12207: 1995 - 0801: Informational Technology - Software life cycle processes.

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

Сбор и анализ требований заказчика исполнителем и представление их в нотации, которая является понятной как для заказчика, так и для исполнителя.

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

Реализация. Преобразование проектных решений на программную систему, которая реализует такие решения.

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

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

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

Программная система - это определенная машина, которая вводится в мир для того, чтобы влиять на него. Части света, которые влияют на машину или подвергаются ее влияния, составляют так называемый домен предметной области (data domain) или домен применения (application domain). Описание этого влияния дает ответ на вопрос: «Что делает система?» и определяет требования к системе в форме соглашений между заказчиком и исполнителем. Как она это делает, определяет описание машины.

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

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

В соответствии с этим, требования к программной системе должны отражать все трудности такой деятельности.

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

Таким образом, на этой фазе договариваются заказчик и исполнитель, определяет дальнейшие действия исполнителя.

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

Действующими лицами процесса формулирования требований являются:

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

- Операторы, которые осуществляют обслуживание во время функционирования системы;

- Разработчики системы.

К процессу формулирования требований входят несколько подпроцессов. Составление требований. Источниками сведений о требованиях могут быть:

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

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

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

а) по первым шагом изучаем физическую структуру действующей системы (Независимо от того, автоматизированная она или «человеческая»)

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

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

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

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

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

1.2 Обзор методов проектирования программного обеспечения

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

- Те, что отражают возможности, которые должна обеспечить система,

назвали функциональными требованиями (functional requirement)

- Те, что отражают ограничения, связанные с функционированием системы, назвали нефункциональными требованиями (notfunctional requirement).

Первая из приведенных категорий дает ответ на вопрос: «Что делает

система? «, а вторая определяет характеристики ее работы, например, что вероятность сбоя системы в течение часа не может превышать одной миллионной.

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

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

- Требования конфиденциальности;

- Отказоустойчивость;

- Число клиентов, которые одновременно имеют доступ к системе;

- Требования безопасности;

- Время ожидания ответа на обращение к системе;

- Исполнительские качества системы (ограничение по ресурсам памяти, скорость реакции на обращение к системе и т.д.).

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

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

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

Определение влияния требований на потребности в ресурсах также шагом процесса анализа требований.

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

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

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

Функционально - ориентированные (структурные) методы базируются на структурном анализе, структурных картах, диаграммах потоков данных и др. Они ориентированы на идентификацию функций и их уточнения сверху - вниз, после чего проводится разработка диаграмм потоков данных (DFD) и описание процессов. Примеры методов структурного проектирования приведены в работах Иордана и Константина[4, 5], Майерса [6].

В качестве средств структурного анализа и проектирования, наиболее распространенные такие нотации:

SADT (Structured Analysis and Design Technique). Для новых систем SADT (IDEF 0) применяется для определения требований (функций) для разработки системы, реализующего отдельные функции. Для уже существующих - IDEF 0 может быть использована для анализа функций, выполняемых системой. Модель в нотации IDEF 0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Вершина этой древовидной структуры представляет собой общее описание системы. После описания системы в целом проводится разбиение ее на крупные фрагменты (функциональная декомпозиция).

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

В свою очередь в MDE относятся такие подходы к проектированию ПО как RUP (Rational Unified Process - «Рациональный унифицированный процесс») и MDA (Model-driven architecture - «Мо дельно - ориентированная архитектура»).

RUP использует итеративную модель разработки ПО и основывается на следующих принципах: Ранняя идентификация и непрерывное (до окончания проекта) устранение основных рисков.

Концентрация на выполнении требований заказчиков к ПО (анализ и построение модели прецедентов (вариантов использования).

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

Компонентная архитектура, реализованная и тестируемая на р анних стадиях проекта.

Постоянное обеспечение качества на всех этапах разработки проекта (продукта).

Работа над проектом командой разработчиков, ключевая роль в которой принадлежит архитекторам.

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

В отличие от RUP, MDA характеризуется следующими преимуществами:

возможность переноса приложения, ее повторное использование, уменьшение стоимости и сложности разработки и упр ния приложением;

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

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

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

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

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

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

Согласно концепции модельно - ориентированного подхода, модель создаваемого программного обеспечения рассматривается с трех точек зрения:

Вычислительная независимая модель (CIM - Computation Independent Model)

- Описание потоков задач, которое включает:

требования предметной области и информацию, используется;

независимые от программной реализации аспекты структуры ПО и вычислений;

CIM базируется на среде функционирования системы, на требованиях к системы, тогда как структура и функционирования системы НЕ детализированные или даже неопределенные.

Независимая от платформы модель (PIM - Platform Independent Model) - HLA (высокоуровневый архитектура ПО ЧП, описание потоков задач, ориентированных на вычисления), которая включает:

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

абстрагирования от платформо - специфических особенностей.

Модель, ориентированная на платформу (PSM - Platform Specific Model) - LLA (низкоуровневая архитектура ПО ЧП), которая включает платформо - специфические особенности реализации услуги на конкретной платформе (подсистемы OSS / BSS).

На рис. 1. изображен принцип реализации MDA. Основная идея MDA заключается в том, что преобразования с PIM в PSM, а также генерации я кода с PSM может осуществляться автоматически. Преобразование проводятся за помощью инструментов преобразования (transformation tools), которые, в свою очередь, используют правила преобразования. Эти правила пользователя на языке, который описана стандартом QVT (Queries, V iews, Transformations). преобразование могут быть параметризованные, что позволит их подстраивать под потребности конкретных проектов.

Рис.1. Преобразование моделей MDA: PIM в PSM

Пример реализации MDA архитектуры

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

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

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

Рис. 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 предполагает, что проектирование - это настолько важный процесс, который необходимо выполнять постоянно в течение всего времени работы над проектом. Проектирование должно выполняться определенными этапами, с учетом требований, которые постоянно изменяются. В каждый момент времени разработчики используют наиболее простой проект системы, который подходит для решения текущей задачи. При этом он меняется по мере того как условия задачи меняются.

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

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

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

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

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

ВЫВОДЫ

Коротко рассмотрены основные подходы и методологии проектирования программного обеспечения: функционально - ориентированные (структурные) методы, компонентное проектирование, методология ARIS, объектно - ориентированное проектировании.

Проведен обзор методов объектно - ориентированное разработки ЭИС.

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

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

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

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

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

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

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

ЛИТЕРАТУРА

Буч Г. Объектно - ориентированный анализ и проектирование с примерами приложений на С ++. [2 - е изд.] / Буч Г. - СПб .: Невский Диалект 2010. - 560 с.
В.А .; Сичная А.А. - Нац . Техн . Унт Украины « Киев , политех , ин - т». Киев, 2011. - 272 с.
Вендров А.М. CASE - технологии. Современные методы и средства проектирования информационных систем / Вендров А.М. - М .: Финансы и статистика , 2014. - 176 с .
Грейди Буч. Язык UML. Руководство пользователя / Грейди Буч, Джеймс Рамбо, Айвар Джекобсон. - СПб .: Питер , 2014. - 432 с .
И. Соммервил. Инженерия программного обеспечения [пер. с англ. - 6- е издание.] / И. Соммервил. - М .: Вильямс, 2012. - 624 с.
Лаврищева институт (государственный университет)] / Лаврищева Е.М., Петрухин В.А .. - Москва,2016 - 304 c.
Майерс Г. Надежность программного обеспеч ения / Пер. с англ. Ю.Ю.Галимова; Под ред. В.Ш.Кауфман. - М .: Мир , 2011. - 360 с .
Основы формальных методов описания бизнес - процессов [yчеб.пособие] / [Самуйлов К.Е., Серебренникова Н.В., Чукарина А.В., Яркина Н.В.] - М .: РУДН , 2012. - 130 с .
Петренко А.И. Основы автоматизированного проектирования ОБ «ОБЪЕКТОВ И СИСТЕМ ( Конспект лекций) / Петренко А.И. - К .: Издательство ВМУРОЛ «Украина» , 2012. - 211 с .
Теленик С.Ф. Адаптивные технологии создания информационно - управляющих систем: ретроспектива и перспектива / Теленик С.Ф. .; Лозинский, 2011.
Черемных С.В. Моделирование и анализ систем. IDEF - технологии: практикум / С . В . Черемных , И . В . Семенов , BC Ручкин . - М .: Финансы и статистика , 2016. - 192 c.
Frank Truyen. Model Driven Architecture With Enterprise Architect, Measuring EA Features to MDA Concepts [ Электронный ресурс ] / Frank Truyen. - Cephas Consulting Corp 2010 - 17 p. - Режим доступа: http://cephas.cc/sitecontent/?q=resources#white-papers
Introduction to business modeling using the Unified Modeling Language (UML) [ Электронный ресурс ] // IBM. - 2013. - Режим дос тупую: http://www.ibm.com/developerworks/rational/library/360.html
Ivar Jacobson. The Unified Software Development Process / Ivar Jacobson, Grady Booc h, James Rumbaugh. - Addison-Wesley Professional, 2010. - 512 pages.
Jackson M. Software requirement & specifications / Jackson M. - Wokingham, England: Addison - Wesley, ACM Press Books, 2015. - 228 p.
Larisa Globa. Modified model driven software development / Larisa Globa «Polish J. of Environ. Stud», Vol. 18, No. 4 А (2011), pp.39 -43.
Max Muhlhauser. Software Engineering Fur Verteilte Anw endungen: Mechanismen Und Werkzeuge / Max Muhlhauser, Alexander Schill. - Springer-Verlag, 2012. - 402 p.
MDA Guide [V ersion 1.0.1, 2013, Document Number: omg / 2013-06-01] [ Электронный ресурс ] // Editors: Joaquin Miller and Jishnu Mukerji, OMG. - 2013. - 62 p. - Режим доступа: http://www.omg.org/mda/mda_files/Model-Driven_Architecture.pdf
Orr K. Structured system development / Orr K. - NY: Yourdon Press, 2010.
Oscar Pastor. Model-Driven Architecture in Practice: A Software Production Environment Based on Conceptual Modeling / Oscar Pastor, Juan Carlos Molina. - Berlin Heilelberg: Springer, 2015. - 302 p.
Per Kroll. Rational Unified Process Made Easy-A Practit ioner's Guide to the RUP / Per Kroll, Philippe Kruchten. - Addison-Wesley, 2013 - 464 p.
Peter Eeles. MDA and RUP [Электронный ресурс] /Peter Eeles. – IBM Software Group, 2014. 38 p. Режим доступа: http://www.architecting.co.uk/presentations/MDA%20and%20RUP.pdf
SAP R / 3 Enterprise [Release 4.70, Extension Set 2.00, March 2014] [ Электронный ресурс ] 84 / frameset.htm http://scrum.org.ua/
Scheer A.-W. Corporate Performance Management: ARIS in Practice / Scheer A.-W., Jost W., He ß H., Kronz A. (editors). - Berlin Heidelberg: Springer, 2016.- 275 pages.
Schmidt DC Model-driven engineering, / Schmidt DC - IEEE Computer, vol. 39, February 2016. - pp. 25-31.
Soundness of Workflow Nets: Classification, Decidability, and Analysis [ Электронный ресурс ] / [WMP van der Aalst, KM van Hee, AHM te r Hofstede and others]. // Formal Aspects of Computing. - 2011. - c. 333-363. - Режим доступа: http://www.springerlink.com/content/t030235944585n44/fulltext.pdf
Yordon E. Structured Design [2nd edition] / Yordon E., Larry L. Constantine. - New York: Yordon Press, 2011. - 700 p.
Yourdon E. Modern Structured Analysis / Yourdon E. - Prentice-Hall, 2010. - 672 p.