13 Agile-манифест

Экстремальное программирование (Extreme Programming, XP) возникло как эволюционный метод разработки ПО «снизу-вверх». Этот подход является примером так называемого метода «живой» разработки (Agile Development Method). В группу «живых» входят, помимо экстремального программирования, методы SCRUM, DSDM (Dynamic Systems Development Method, Метод разработки динамичных систем), Feature-Driven Development (Разработка, управляемая характеристиками результата) и пр.

Основные принципы «живой» разработки ПО зафиксированы в манифесте «живой» разработки [3]. Люди и взаимодействие важнее процессов и инструментов Работающий продукт важнее исчерпывающей документации Сотрудничество с заказчиком важнее согласования условий контракта Готовность к изменениям важнее следования первоначальному плану 

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

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

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

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

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

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

Работающий продукт — основной показатель прогресса.

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

Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.

Простота — искусство минимизации лишней работы — крайне необходима.

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

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

14

IDEF — методологии семейства ICAM (Integrated Computer-Aided Manufacturing) для решения задач моделирования сложных систем, позволяет отображать и анализировать модели деятельности широкого спектра сложных систем в различных разрезах. При этом широта и глубина обследования процессов в системе определяется самим разработчиком, что позволяет не перегружать создаваемую модель излишними данными.

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

Развитие методик было начато в 1945 г. Ludwig von Bertallanfly. В основе лежат следующие постулаты: любая система есть совокупность систем, система всегда имеет некоторые границы, система преобразует входы в выходы используя механизмы, у системы есть управляющее воздействие, описание системы зависит от цели, области и точки зрения.

Собственно IDEF есть некоторое формализованное описание разложения изучаемой системы на подсистемы (декомпозиция) в зависимости от области применения, состава экспертной группы и назначений. Техника моделирования функциональной декомпозиции была развита в 60-х годах Douglas T.Ross для улучшения производства. Первым был стандарт IDEF0 (называвшийся в начале SADT), упрощенная версия которого принята ВВС США в 70-х годах. Использование методик моделирования бизнес процессов дало хорошие результаты в процессе реорганизации производства и управления. В дальнейшем, используя методологию проектирования, IDEF развился и продолжает развиваться. Описание наиболее распространенных стандартов можно найти на www.idef.com.

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

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

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

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

При этом связи могут присутствовать не всегда все и связывать данную сущность с другими.

Рис. 1 Простейшая «сущность-связь» диаграмма

Необходимо также иметь в виду, что не существует «абсолютной» модели, т.е. которая полностью описывает деятельность какого-либо предприятия. Любое моделирование происходит на уровне описания одной из сторон деятельности или управления (например: бухгалтерский учет, документооборот, технологический цикл и т.п.). Да и задачи, решаемые в результате моделирования, совершенно различны: в одном случае это анализ технологий фирмы на предмет их улучшения, в другом случае – структурная реорганизация предприятия, в третьем – создание информационной системы управления, и т.д. Конечно, в некотором смысле такие модели подобны – более того, взаимосвязаны. Более того, чтобы построить наиболее функциональную систему автоматизации, необходимо построить достаточное количество подобных моделей.

Как правило, методы IDEF устанавливают стандарт описания деятельности человека в соответствии с некоторым мировоззрением. Рассмотрим некоторые из них.

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