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

ВВЕДЕНИЕ

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

---