Файл: Учебное пособие.doc

бизнес-моделирование. Моделируется информационный поток между бизнес-функциями. Ищется ответ на следующие вопросы: Какая информация руководит бизнес-процессом? Какая генерируется информация? Кто генерирует ее? Где информация применяется? Кто обрабатывает ее?
моделирование данных. Информационный поток, определенный на этапе бизнес-моделирования, отображается в набор объектов данных, которые требуются для поддержки бизнеса. Идентифицируются характеристики (свойства, атрибуты) каждого объекта, определяются отношения между объектами;
моделирование обработки. Определяются преобразования объектов данных, обеспечивающие реализацию бизнес-функций. Создаются описания обработки для добавления, модификации, удаления или нахождения (исправления) объектов данных;
генерация приложения. Предполагается использование методов, ориентированных на языки программирования 4-го поколения. Вместо создания ПО с помощью языков программирования 3-го поколения, RAD-процесс работает с повторно используемыми программными компонентами или создает повторно используемые компоненты. Для обеспечения конструирования используются утилиты автоматизации;

Рис. 1.14. Модель быстрой разработки приложений

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

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

Применение RAD имеет и свои недостатки, и ограничения.

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

1.2.5.Компонентно-ориентированная модель

Компонентно-ориентированная модель является развитием спиральной. В этой модели конкретизируется содержание квадранта конструирования – оно отражает тот факт, что в современных условиях новая разработка должна основываться на повторном использовании существующих программных компонентов (Рис. 1 .15).

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

Достоинства компонентно-ориентированной модели:
уменьшает на 30% время разработки программного продукта;
уменьшает стоимость программной разработки до 70%;
увеличивает в полтора раза производительность разработки.
Недостатком такой модели является сложность организации процесса разработки ПО по данной модели.

1.2.6.XP-процесс

Экстремальное программирование (eXtreme Programming, XP) – облегченный (подвижный) процесс (или методология), главный автор которого – Кент Бек (1999). ХР- процесс ориентирован на группы малого и среднего размера, строящие программное обеспечение в условиях неопределенных или быстро изменяющихся требований. ХР- группу образуют до 10 сотрудников, которые размещаются в одном помещении.

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

Оценивание заказчиком

Планирование

Рис. 1.15. Компонентно-ориентированная модель

Большинство принципов, поддерживаемых в ХР (минимальность, простота, эволюционный цикл разработки, малая длительность итерации, участие пользователя, оптимальные стандарты кодирования и т. д.), продиктованы здравым смыслом и применяются в любом упорядоченном процессе. Просто в ХР эти принципы достигают «экстремальных значений» (Таблица 1 .1).

Таблица 1.1

Экстремумы в экстремальном программировании

Практика здравого смысла	ХР- экстремум	ХР- реализация
Проверки кода	Код проверяется все время	Парное программирование
Тестирование	Тестирование выполняется все время, даже с помощью заказчиков	Тестирование модуля, функциональное тестирование
Проектирование	Проектирование является частью ежедневной деятельности каждого разработчика	Реорганизация (refactoring)
Простота	Для системы выбирается простейшее проектное решение, поддерживающее ее текущую функциональность	Самая простая вещь, которая могла бы работать
Архитектура	Каждый постоянно работает над уточнением архитектуры	Метафора
Тестирование интеграции	Интегрируется и тестируется несколько раз в день	Непрерывная интеграция
Короткие итерации	Итерации являются предельно короткими, продолжаются секунды, минуты, часы, а не недели, месяцы или годы	Игра планирования

Тот, кто принимает принцип «минимального решений» за хакерство, ошибается; в действительности ХР – строго упорядоченный процесс. Простые решения, имеющие высший приоритет, в настоящее время рассматриваются как наиболее ценные части системы, в отличие от проектных решений, которые пока не нужны, а могут (в условиях изменения требований и операционной среды) и вообще не понадобиться. Базис ХР образуют перечисленные ниже двенадцать методов.

Игра планирования (Planning game) – быстрое определение области действия следующей реализации путем объединения деловых приоритетов и технических оценок. Заказчик формирует область действия, приоритетность и сроки с точки зрения бизнеса, а разработчики оценивают и прослеживают продвижение (прогресс).
Частая смена версий (Small releases) – быстрый запуск в производство простой системы. Новые версии реализуются в очень коротком (двухнедельном) цикле.
Метафора (Metaphor) – вся разработка проводится на основе простой, общедоступной истории о том, как работает вся система.
Простое проектирование (Simple design) – проектирование выполняется настолько просто, насколько это возможно в данный момент.
Тестирование (Testing) – непрерывное написание тестов для модулей, которые должны выполняться безупречно; заказчики пишут тесты для демонстрации законченности функций. «Тестируй, а затем кодируй» означает, что входным критерием для написания кода является «отказавший» тестовый вариант.
Реорганизация (Refactoring) – система реструктурируется, но ее поведение не изменяется; цель – устранить дублирование, улучшить взаимодействие, упростить систему или добавить в нее гибкость.
Парное программирование (Pair programming) – весь код пишется двумя программистами, работающими на одном компьютере.
Коллективное владение кодом (Collective ownership) – любой разработчик может улучшать любой код системы в любое время.
Непрерывная интеграция (Continuous integration) – система интегрируется и строится много раз в день, по мере завершения каждой задачи. Непрерывное регрессионное тестирование, то есть повторение предыдущих тестов, гарантирует, что изменения требований не приведут к регрессу функциональности.
40-часовая неделя (40-hour week) – как правило, работают не более 40 часов в неделю. Нельзя удваивать рабочую неделю за счет сверхурочных работ.
Локальный заказчик (On-site customer) – в группе все время должен находиться представитель заказчика, действительно готовый отвечать на вопросы разработчиков.
Стандарты кодирования (Coding standards) – должны выдерживаться правила, обеспечивающие одинаковое представление программного кода во всех частях программной системы.

1.3.Стандарты, регламентирующие процесс разработки программного обеспечения

1.3.1.ГОСТ Р ИСО 9000-2001. Системы менеджмента качества. Основные положения и словарь

1.3.1.1.Предисловие

Стандарт разработан Всероссийским научно-исследовательским институтом сертификации (ВНИИС). Представляет собой аутентичный текст международного стандарта ИСО 9000-2000 "Системы менеджмента качества. Основные положения и словарь".

1.3.1.2.Введение

Семейство стандартов ИСО 9000, перечисленных ниже, было разработано для того, чтобы помочь организациям всех видов и размеров внедрять и обеспечивать функционирование эффективных систем менеджмента качества:

ГОСТ Р ИСО 9000-2001 описывает основные положения систем менеджмента качества и устанавливает терминологию для систем менеджмента качества;
ГОСТ Р ИСО 9001-2001 определяет требования к системам менеджмента качества для тех случаев, когда организации необходимо продемонстрировать свою способность предоставлять продукцию, отвечающую требованиям потребителей и установленным к ней обязательным требованиям, и направлен на повышение удовлетворенности потребителей;
ГОСТ Р ИСО 9004-2001 содержит рекомендации, рассматривающие как результативность, так и эффективность системы менеджмента качества. Целью этого стандарта является улучшение деятельности организации и удовлетворенность потребителей и других заинтересованных сторон;
ИСО 19011* содержит методические указания по аудиту (проверке) систем менеджмента качества и охраны окружающей среды.

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

Принципы менеджмента качества

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

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

а) Ориентация на потребителя

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

б) Лидерство руководителя

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

в) Вовлечение работников

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

г) Процессный подход

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

д) Системный подход к менеджменту

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

е) Постоянное улучшение

Постоянное улучшение деятельности организации в целом следует рассматривать как ее неизменную цель.

ж) Принятие решений, основанное на фактах

Эффективные решения основываются на анализе данных и информации.

и) Взаимовыгодные отношения с поставщиками

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

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

1.3.1.3.Область применения

Настоящий стандарт устанавливает основные положения систем менеджмента качества, являющихся объектом стандартов семейства ИСО 9000, и определяет соответствующие термины.

Настоящий стандарт может использоваться:

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

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

в) пользователями продукции;

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

д) теми сторонами, внутренними или внешними по отношению к организации, которые оценивают систему менеджмента качества или проверяют ее на соответствие требованиям ГОСТ Р ИСО 9001 (например аудиторы, органы по сертификации/регистрации);

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

ж) разработчиками соответствующих стандартов.

1.3.1.4.Основные положения систем менеджмента качества

Обоснование необходимости систем менеджмента качества

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

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