Технологии разработки программных систем

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

Стандарт предназначен для использования:

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

- организацией - для формирования среды необходимых процессов и оценки соответствия между заявленной и утверждённой моделью ЖЦ и её конкретной реализацией;

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

Стандарт обеспечивает основы для моделирования и реализации общих процессов, составляющих ЖЦ систем, предоставляя возможность для их оценки и совершенствования, и, охватывая все концепции и идеи, имеющие отношение к этим системам, начиная от замысла и вплоть до момента снятия с эксплуатации. Процессы ЖЦ, задаваемые стандартом, могут использоваться однократно, многократно или рекурсивно, как по отношению к системе в целом, так и к любым её элементам, применяться для систем единичного и массового производства, а также адаптируемых к требованиям организации и/или проекта.

Рис.3.12. Взаимосвязь между группами процессов

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

Стандарт представляет ЖЦ системы (аналогично ЖЦ ПО в предыдущем стандарте) как структуру дробления работ.

Стандарт описывает следующие 26 процессов ЖЦ системы, объединённые в 5 групп (рис.3.12):

1. Договорные процессы (контрактные процессы, процессы [выработки] соглашений): 1. Приобретение [системы]; 2. Поставка [системы].

2. Организационные процессы (обеспечивающие процессы, процессы предприятия, процессы [уровня] организаций): 1. Управление инфраструктурой / Управление окружением; 2. Управление инвестициями / Управление портфелем проектов; 3. Управление процессами ЖЦ / Управление моделью ЖЦ; 4. Управление ресурсами / Управление персоналом; 5. Управление качеством.

3. Проектные процессы (процессы предприятия, процессы [уровня] проекта):

- Процессы управления проектами: 1. Планирование [проекта]; 2. Мониторинг / Управление выполнением и контроль [проекта].

- Процессы поддержки проектов: 3. Оценивание / Измерение; 4. Управление решениями / Выработка решений; 5. Управление рисками; 6. Управление конфигурацией; 7. Управление информацией.

4. Технические процессы: 1. Определение требований [заинтересованных лиц]; 2. Анализ требований; 3. Проектирование архитектуры; 4. Реализация / Изготовление; 5. Интеграция / Комплексирование; 6. Верификация / Проверка; 7. Переход / Ввод в действие; 8. Аттестация / Валидация; 9. Эксплуатация / Функционирование; 10. Сопровождение / Обслуживание; 11. Снятие с эксплуатации / Вывод из действия.

5. Специальные процессы: 1. Настройка / Адаптация.

Стандарт также описывает следующие 6 стадий ЖЦ системы:

1. Формирование концепции: анализ потребностей, выбор концепции и проектных решений.

2. Разработка: проектирование системы.

3. Реализация: изготовление системы.

4. Эксплуатация: ввод в действие и использование системы.

5. Поддержка: обеспечение функционирования системы.

6. Снятие с эксплуатации: прекращение использования, демонтаж, архивирование системы.

Крайне важной для практики является детализация стандарта до уровня целей, результатов и конкретных действий. Помимо процессов стандарт определяет 208 действий и 123 различных результата этих действий.

Контрольные вопросы

Вопросы к §3.1

1. Дайте определение понятию «жизненный цикл ПО».

2. Дайте определение понятию «модель ЖЦ».

3. Дайте определение понятию «технология» («технологический подход»).

4. Каким образом характеризуется технология?

5. Дайте определение понятию «действие». Какие наборы действий выделяют?

6. Дайте определение понятию «процесс».

7. Приведите и поясните иерархию понятий, связанных с процессом.

8. Дайте определение понятиям «дисциплина» и «поток работ».

9. Дайте определение понятию «процедура» и поясните его.

10. Дайте определение понятию «стадия».

11. Приведите и поясните иерархию понятий, связанных со стадией.

12. Сформулируйте описание измерений технологии.

13. Дайте определение понятиям «методика» и «практика».

14. Перечислите ограничения проекта. Как они связаны с подходом разработки?

15. Дайте определение понятиям, связанным с произведённым результатом.

16. Дайте определение понятиям «артефакт» и «рабочий продукт».

17. Дайте определение понятиям «базовая линия» и «базовый план».

18. Дайте определение понятиям «контрольная точка» и «веха».

19. Дайте определение понятиям «итерация» и «таймбокс».

20. Как понятия, связанные с формализацией, характеризуют технологию?.

Вопросы к §3.2

21. Перечислите и поясните основные наборы технологических процессов.

22. Приведите классические технологические процессы.

23. Приведите группы стандартных технологических процессов.

24. Перечислите и поясните виды формирования технологических стадий.

25. Приведите классические стадии.

26. Приведите и поясните основные фазы.

27. Приведите и поясните дополнительные фазы.

28. Дайте определение понятию «цикл».

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

30. Перечислите классы технологических подходов. В чём заключаются особенности их применения и предъявляемые основные требования?

31. Приведите группы технологических подходов в рамках каждого класса.

Вопросы к §3.3

32. Перечислите основные модели ЖЦ ПО.

33. В чём суть непланируемой модели? Приведите графическое представление этой модели.

34. В чём суть классической каскадной модели? Приведите графическое представление этой модели.

35. В чём суть модифицированной каскадной модели? Приведите графическое представление этой модели.

36. В чём суть прототипируемой модели? Объясните название этой модели.

37. В чём суть классической модели прототипирования? Приведите графическое представление этой модели.

38. В чём суть итеративной инкрементной модели? Приведите графическое представление этой модели.

39. В чём суть эволюционной модели? Приведите графическое представление этой модели.

40. В чём суть спиральной модели? Объясните название этой модели.

41. В чём суть классической спиральной модели? Приведите графическое представление этой модели.

42. Охарактеризуйте особенность классической спиральной модели. Что такое риск? Перечислите наиболее распространённые риски.

43. Перечислите ключевые практики для классической спиральной модели.

44. Перечислите контрольные точки для классической спиральной модели.

45. В чём суть модифицированной спиральной модели? Приведите графическое представление этой модели.

46. Перечислите контрольные точки для модифицированной спиральной модели.

Вопросы к §3.4

47. Дайте определение классическому процессу «Исследование идеи».

48. Дайте определение классическому процессу «Управление».

49. Поясните понятия, связанные с целью проекта.

50. Дайте определение классическому процессу «Анализ».

51. Дайте определения понятиям, связанным с требованиями.

52. Дайте определения понятиям, связанным со спецификациями.

53. Дайте определение классическому процессу «Проектирование».

54. Дайте определения понятиям, связанным с системой.

55. На какие подпроцессы разделяется проектирование? В чём они заключаются?

56. Дайте определения понятиям, связанным с архитектурой ПО.

57. Дайте определение классическому процессу «Кодирование».

58. Дайте определение понятию «конструирование».

59. Перечислите фундаментальные основы конструирования.

60. Дайте определение классическому процессу «Тестирование».

61. Что включает в себя тестирование.

62. Что представляет собой инспектирование?

63. Дайте определение классическому процессу «Ввод в действие».

64. Дайте определение классическому процессу «Сопровождение».

65. Сформулируйте основной принцип сопровождения.

66. Перечислите категории сопровождения.

67. Перечислите уровни модификации ПО. Как они связаны с сопровождением?

68. Дайте определение классическому процессу «Снятие с эксплуатации».

Вопросы к §3.5

69. Перечислите и поясните способы декомпозиции систем.

70. Дайте определения понятиям, связанным с моделями и методами анализа и проектирования.

71. Перечислите основные модели и методы анализа требований для структурной методологии.

72. Перечислите основные модели и методы анализа требований для объектно-ориентированной методологии.

73. Перечислите основные модели и методы проектирования архитектуры для структурной методологии.

74. Перечислите основные модели и методы проектирования архитектуры для объектно-ориентированной методологии.

75. Перечислите основные модели и методы проектирования компонентов для структурной методологии.

76. Перечислите основные модели и методы проектирования компонентов для объектно-ориентированной методологии.

77. Перечислите основные подходы (методики) к анализу и проектированию для структурной методологии.

78. Перечислите основные подходы (методики) к анализу и проектированию для объектно-ориентированной методологии.

Вопросы к §3.6

Стандарт ISO/IEC 12207

79. В чём заключается цель стандарта ISO/IEC 12207:1995?

80. Как определяется ЖЦ в стандарте ISO/IEC 12207:1995?

81. Какие элементы ЖЦ выделены в стандарте ISO/IEC 12207:1995? Приведите и поясните иерархию элементов ЖЦ. На чём базируется разбиение процесса.

82. Перечислите и поясните принципы выделения стандартных процессов.

83. Перечислите группы стандартных процессов. Приведите графическое представление групп процессов.

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

85. Перечислите точки зрения на процессы основных заинтересованных лиц.

86. Перечислите основные процессы стандарта ISO/IEC 12207:1995.

87. Перечислите вспомогательные процессы стандарта ISO/IEC 12207:1995.

88. Перечислите организационные процессы стандарта ISO/IEC 12207:1995.

89. Перечислите стадии по стандарту ISO/IEC 12207:1995.

90. Дайте краткое описание стандартного процесса «Приобретение». Перечислите включаемые в него действия.

91. Дайте краткое описание стандартного процесса «Поставка». Перечислите включаемые в него действия.

92. Дайте краткое описание стандартного процесса «Разработка». Перечислите включаемые в него действия.

93. Дайте краткое описание стандартного процесса «Эксплуатация». Перечислите включаемые в него действия.

94. Дайте краткое описание стандартного процесса «Сопровождение». Перечислите включаемые в него действия.

95. Дайте краткое описание вспомогательных стандартных процессов.

96. Дайте краткое описание организационных стандартных процессов.

97. Дайте краткое описание процесса адаптации стандарта. Перечислите включаемые в него действия.

98. Как определяется соответствие проекта стандарту ISO/IEC 12207:1995?

99. Как обеспечивается возможность использования организацией стандарта ISO/IEC 12207:1995 в своих договорах?

Стандарт ISO/IEC 15288

100. В чём заключается назначение стандарта ISO/IEC 15288:2002?

101. Приведите группы процессов по стандарту ISO/IEC 15288:2002. Приведите графическое представление взаимосвязи групп процессов.

102. Перечислите договорные процессы стандарта ISO/IEC 15288:2002.

103. Перечислите организационные процессы стандарта ISO/IEC 15288:2002.

104. Перечислите проектные процессы стандарта ISO/IEC 15288:2002.

105. Перечислите технические процессы стандарта ISO/IEC 15288:2002.

106. Перечислите специальные процессы стандарта ISO/IEC 15288:2002.

107. Перечислите стадии по стандарту ISO/IEC 15288:2002.



Раздел 4. Подходы разработки ПО

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

Многие подходы используют для своего описания понятия «процесс», «процесс разработки ПО» или «процесс разработки системы», под которым понимается собственно подход к разработке, а не какой-либо конкретный процесс ЖЦ, описываемый этим подходом. Кроме того, в названиях подходов можно встретить и такие понятия, как «каркас», «метод», «методология», «доставка», «разработка» и «инженерия» и т.п. Это связано прежде всего со следующими факторами:

- ориентация подхода на конкретные проекты и предлагаемые решения;

- использование в подхода определённых процессов и стадий ЖЦ;

- рекламная политика соответствующей фирмы, продвигающей подход.

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

4.1 Каскадные технологические подходы

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

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

Выделяют каскадные подходы следующих двух видов:

1. Простые каскадные подходы: классический и модифицированный.

2. Развитые каскадные подходы: каскадно-возвратный, каскадно-итерационный, каскадно-перекрывающийся и каскадно-декомпозиционный.

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

Модели ЖЦ для простых каскадных подходов приведены в §3.3.

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

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

Модели ЖЦ для развитых каскадных подходов приведены при изложении соответствующих подходов.

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



Рис.4.1. Каскадно-возвратная модель

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

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

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



Рис.4.2. Каскадно-итерационная модель

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

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

Рис.4.3. Каскадно-перекрывающаяся модель

Рис.4.4. Каскадно-декомпозиционная модель

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

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

Каскадно-декомпозиционная модель является каскадной моделью с учётом декомпозиции системы на модули и представляет собой модель с параллелизмом подпроцессов. Принцип модели (рис.4.4) заключается в разделении проекта на подпроекты по числу выделенных компонентов и/или имеющихся команд.

4.2 Каркасные технологические подходы

Каркасные подходы являются развитием каскадных подходов на основе применения развитых моделей ЖЦ и адаптации к современным организационным и экономическим условиям. Поэтому в настоящее время среди строгих подходов именно они чаще применяются на практике.

Выделяют каркасные подходы следующих двух видов:

1. Унифицированные каркасные подходы: Унифицированный процесс (UP) и его модификации, Рациональный унифицированный процесс (RUP).

2. Специализированные каркасные подходы: Каркас решений Майкрософт (MSF), Процесс ICONIX (ICONIX Process), Модельно-основанная (системная) архитектура и программная инженерия (MBASE).

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

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

Унифицированный процесс (UP)

Унифицированный процесс (УП, UP - Unified Process) - классический унифицированный каркасный подход, развиваемый самостоятельно, отдельно от унифицированного каркасного подхода, предлагаемого фирмой IBM Rational.

Первая книга, в которой был описан этот подход,- «Унифицированный процесс разработки ПО» («The Unified Software Development Process») сотрудников Rational Software А. Якобсона, Г. Буча и Дж. Рамбо. Она была опубликована в 1999 г. В дальнейшем авторы книги предпочли для этого подхода название Rational Unified Process. Авторы последующих публикаций по этой тематике, не являющиеся сотрудниками этой фирмы, используют название Unified Process. Это позволяет также исключить проблемы с нарушением авторских прав на RUP и Rational Unified Process - торговые марки IBM.

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

УП обладает следующими особенностями: 1. Итеративность и инкрементность; 2. Управляемость прецедентами; 3. Ориентированность на архитектуру; 4. Сосредоточенность на рисках.

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

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

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

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

Модель ЖЦ для УП отражает объём работ каждой дисциплины во всех фазах ЖЦ (рис.4.5).

Рис.4.5. Модель ЖЦ для подхода UP

В УП выделены 4 фазы: 1. Начало; 2. Уточнение; 3. Построение; 4. Внедрение. Каждая из фаз включает ряд итераций (с учётом фазы и проекта). На протяжении этих фаз по проекту выполняются работы, сгруппированные в следующие дисциплины (рис.4.5): 1. Бизнес-моделирование; 2. Определение требований; 3. Анализ и проектирование; 4. Реализация; 5. Тестирование; 6. Развёртывание.

Конец каждой фазы является некоторой вехой. Всего выделено 4 вехи:

1. Цели ЖЦ (LCO). Веха определяется достижением договорённости о жизнеспособности проекта и формированием базового плана.

2. Архитектура ЖЦ (LCA). Веха определяется подтверждением выбора подхода на основе архитектуры в простейшей форме.

3. Начальный операционный вариант (IOC). Веха определяется доступностью решения, годного к употреблению.

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

Как следует из названий, дисциплины УП являются подмножеством действий стандартного процесса «Разработка», кроме того используется пофазное формирование стадий. В отличие от процессов каскадного подхода все дисциплины УП выполняются практически во всех фазах ЖЦ. Для дисциплин в зависимости от фазы применяется соответствующая целевая установка проекта и определяется соответствующий объём работ (рис.4.5).

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

Основными модификациями УП являются:

- Рациональный УП (РУП) - Rational UP (RUP) - детализация УП от IBM / Rational Software.

- Живой УП, или Активный УП - Agile UP (AUP) - гибкий вариант РУП от С.У. Амблера.

- Базисный УП - Basic UP (BUP) - гибкий вариант РУП от IBM.

- Корпоративный УП, или УП предприятия - Enterprise UP (EUP) - расширение РУП от С.У. Амблера.

- Сущностный УП - Essential UP (EssUP) - гибкий усовершенствованный вариант РУП от А. Якобсона.

- Открытый УП - Open UP (OpenUP) - часть EPF от Eclipse Foundation.

- Открытый/базисный УП - Open UP/Basic (OpenUP/Basic) - гибкая вариация OpenUP от IBM.

- Рациональный УП - Системная инженерия - Rational UP - System Engineering (RUP_SE) - версия РУП от Rational Software для Системной инженерии.

- Унифицированный метод Оракл - Oracle Unified Method (OUM) - собственный вариант УП от Oracle.

- УП для образования - Unified Process for Education (UPEDU) - вариант РУП, приспособленный для обучения.

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

Рациональный унифицированный процесс (RUP)

Рациональный унифицированный процесс (РУП, RUP - Rational Unified Process) - унифицированный каркасный подход, предлагаемый фирмой Rational Software Corporation (с 2003 г. - подразделение IBM Corporation); поэтому возможен и другой перевод названия: Унифицированный процесс [от] Rational Software.

Исторически РУП является развитием подхода Объекторный Процесс (Objectory Process), принятого в компании Ericsson в 70_х - 80_х гг. XX в. Объекторный Процесс был создан А. Якобсоном как дальнейшее развитие его методики Объектно-ориентированная инженерия ПО. Впоследствии, в 1987 г., автор основал собственную компанию Objectory AB именно для развития своего технологического подхода разработки ПО как отдельного продукта, который можно было бы переносить в другие организации. После вливания Objectory AB в Rational в 1995 г. подход Якобсона был объединён с Рациональным Подходом (Rational Approach). Рациональный подход основан на работах У. Ройса, Ф. Крухтена и Г. Буча.

Объединённый подход вначале получил название Рациональный Объектный Процесс (РОП, ROP - Rational Objectory Process), затем, после включения поддержки бизнес-моделирования, переименован в РУП. Кроме этого в подход была включена развивавшаяся в это время сотрудниками Rational объектно-ориентированная методика анализа и проектирования, получившая название языка UML.

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

Rational Unified Process является также продуктом, предоставляемым IBM Rational. В этом качестве он представляет собой структурированную интерактивную базу знаний с шаблонами артефактов и подробным описанием различных типов действий, которое включает в себя общие принципы, конкретные рекомендации и примеры по эффективной разработке систем. База знаний регулярно обновляется и совершенствуется с учётом передового опыта.

Этот продукт входит как составная часть в набор инструментальных средств IBM Rational для поддержки РУП. Некоторые из этих средств благодаря возможности их расширения оказываются применимыми в качестве инструментария для других подходов. В частности, подход MSF долгое время основывался на этом наборе до разработки собственного набора средств.

Основы подхода

Исследование различных неудачных проектов привело авторов РУП к выявлению признаков и первопричин их провала.

Основными считаются следующие первопричины:

1. Непланируемое управление требованиями.

2. Неоднозначное и неопределённое взаимодействие.

3. Хрупкая архитектура (архитектура, не работающая в стрессовых условиях).

4. Непреодолимая сложность.

5. Необнаруженные несогласованности между требованиями, дизайном и реализацией.

6. Недостаточное тестирование.

7. Субъективная оценка состояния проекта.

8. Провал из-за накопившихся рисков.

9. Неконтролируемое распространение изменений.

10. Недостаточная автоматизация.

Проявлениями первопричин считаются следующие признаки:

1. Неточное понимание потребностей конечных пользователей.

2. Неспособность иметь дело с изменяющимися требованиями.

3. Не соответствующие друг другу модули.

4. Тяжёлое для сопровождения и расширения ПО.

5. Позднее обнаружение серьёзных недостатков в проекте.

6. Плохое качество ПО.

7. Неприемлемая производительность ПО.

8. Невозможность участников проекта даже совместно определить (или вспомнить), кто что изменил, когда, где и почему.

9. Ненадёжный процесс построения и выпуска.

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

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

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

Лучшими считаются следующие практики, используемые в РУП: 1. Итеративная разработка; 2. Управление требованиями; 3. Использование компонентной архитектуры; 4. Визуальное моделирование; 5. Проверка качества; 6. Контроль изменений.

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

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

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

- концентрация усилий на наиболее важных направлениях проекта;

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

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

- равномерное распределение ресурсов проекта;

- реальная оценка текущего состояния проекта.

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

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

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

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

- объективная оценка состояния проекта на основе реализованной функциональности и текущей производительности системы;

- раннее обнаружение различных несоответствий и расхождений;

- использование инструментальных средств для организации более эффективного процесса управления требованиями.

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

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

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

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

- упрощения задач по управлению конфигурацией продукта;

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

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

- однозначно описать функциональное поведение разрабатываемой системы;

- определить архитектурно значимые компоненты системы и сосредоточится на их реализации;

- обеспечить построение гибкой и надёжной архитектуры и системы в целом;

- исключить из рассмотрения второстепенные детали, не влияющие на решение задачи;

- выявить на ранних стадиях проекта ошибки проектирования и несогласованность в реализации отдельных компонент системы.

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

- производит оценку состояния проекта по объективным показателям;

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

- акцентирует внимание на тех сторонах работы системы, которые имеют наибольшую важность и повышенный риск;

- дефекты выявляются на ранних этапах, снижая затраты на их устранение;

- автоматизированное тестирование обеспечивает снижение влияния «человеческого фактора» и повторяемость результатов.

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

- контроль состояния проекта в целом и отдельных задач на основании статусов запросов на изменение;

- хранение историй изменений по каждому запросу на изменение;

- актуальную информацию по загрузке участников проекта;

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

- учёт трудозатрат участников проекта по выполняемым изменениям;

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

Лучшие практики послужили основой для создания подхода РУП.

РУП основан на наборе из 6 ключевых принципов бизнес-управляемой разработки, сокращённо называемый ABCDEF:

1. Адаптация процесса.

2. Баланс приоритетов заинтересованных лиц.

3. Сотрудничество между командами.

4. Демонстрация результата итерационно.

5. Эволюция (рост) уровня абстракции.

6. Фокусировка непрерывно на качестве.

Эти принципы были определены П. Кроллом и У. Ройсом.

Жизненный цикл проекта

Модель ЖЦ для РУП отражает объём работ каждой дисциплины во всех фазах ЖЦ (рис.4.6).

В РУП, как и в УП, также выделены 4 фазы, состоящие из ряда итераций.

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

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

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

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

Рис.4.6. Модель ЖЦ для подхода RUP

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

На протяжении этих фаз по проекту выполняются группы работ - дисциплины. РУП выделяет 6 основных и 3вспомогательных дисциплины (рис.4.6).

Основные дисциплины, совпадающие с дисциплинами УП:

1. Бизнес-моделирование.

2. Определение требований.

3. Анализ и проектирование.

4. Реализация.

5. Тестирование.

6. Развёртывание.

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

1. Управление конфигурацией и изменениями.

2. Управление проектом.

3. Управление средой.

Приведём краткую характеристику всех дисциплин.

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

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

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

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

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

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

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

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

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

По трудоёмкости и затратам времени (на один цикл) фазы ЖЦ распределяются следующим образом (рис.4.7): Построение, Уточнение, Внедрение и Начало.

Нагрузка основных дисциплин РУП распределяется по фазам следующим образом: в фазе Начала - Бизнес-моделирование и Определение требований, в фазе Уточнения - Анализ и проектирование и Реализация, в фазе Построения - Реализация и Тестирование, в фазе Внедрения - Развёртывание.

Рис.4.7. Трудоёмкость и затраты времени на фазы



Рис.4.8. Итеративность разработки

В каждой итерации выполняются все дисциплины РУП, но с разной интенсивностью, зависящей от фазы, и в определённой взаимосвязи (рис.4.8).

Каркас решений Microsoft (MSF)

Каркас решений Microsoft или Фреймворк для создания решений от Microsoft (МСФ, MSF - Microsoft Solutions Framework) - каркасный подход, предлагаемый фирмой Microsoft Corporation.

MSF 1.0 был представлен в 1993 г. MSF 4.0 выпущена в 2005 г.

МСФ представляет собой каркас процессов, основанных на принципах и использующих опробованные практики.

Microsoft Solutions Framework является также продуктом, предоставляемым Microsoft. В этом качестве он представляет собой базу знаний в виде пакета руководств, разделённого на несколько белых книг - документов, каждый из которых охватывает определённую модель или дисциплину. Он входит в набор инструментальных средств Microsoft Visual Studio Team System для поддержки МСФ. До его разработки Microsoft основывалась на наборе IBM Rational.

МСФ 4.0 состоит из 5 белых книг: Модель руководства МСФ, Модель проектной группы МСФ, Дисциплина управления проектами МСФ, Дисциплина управления рисками МСФ, Дисциплина управления подготовкой МСФ.

В целом МСФ не является таким тяжеловесным подходом как РУП и во многом опирается на конкретные практики.

Основы подхода

МСФ основан на наборе из 9 основополагающих принципов: 1. Работа в рамках единого видения; 2. Проявление живости, ожидание изменений; 3. Сотрудничество с заказчиками; 4. Поощрение свободного общения; 5. Обучение на любом опыте; 6. Вкладывание [денег] в качество; 7. Поставка инкрементного результата; 8. Установление ясной подотчётности; 9. Наделение полномочиями членов команды. Принципы формируют общую суть моделей и дисциплин МСФ.

МСФ предлагает набор из 9 ключевых концепций: 1. Фокусировка на конечном результате; 2. Поддержка своей клиентуры; 3. Чувство гордости за мастерство; 4. Просмотр всей картины; 5. Поставка на своих обязательствах; 6. Практика хорошего гражданства; 7. Поощрение команды равных; 8. Непрерывное обучение; 9. Усвоение качеств обслуживания. В МСФ 4.0 они названы мыслеукладами из-за стремлением Microsoft к созданию и внедрению своей культуры разработки. В МСФ 4.0 концепции названы мыслеукладами (тж. умонастроения) в связи со стремлением Microsoft к созданию и внедрению своей культуры разработки.

Модель руководства МСФ обладает следующими тремя особенностями: 1. Итеративный подход; 2. Подход, основанный на фазах и вехах; 3. Целостный подход к созданию и внедрению решений.

Жизненный цикл проекта

Модель ЖЦ для МСФ отражает один цикл разработки (рис.4.9).

В МСФ выделено всего 5 фаз: 1. Представление; 2. Планирование; 3. Разработка; 4. Стабилизация; 5. Развёртывание. Все фазы разграничены главными вехами. Для повышенного управления проектом внутри фаз выделяют ряд промежуточных вех, показывающих достижение результата в некоторой деятельности.

Рис.4.9. Модель ЖЦ для подхода MSF

На фазе 1 «Представление» выполняется создание и сплочение команды на основе выработки единого видения. Основными задачами являются создание ядра команды (т.е. назначение ключевых членов) и подготовка документа с описанием концепции проекта, включающего видение и содержание проекта.

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

Результатами этой фазы являются: Описание видения и содержания, Документ оценки рисков, Описание структуры проекта.

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

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

Результатами этой фазы являются: Функциональная спецификация, План управления рисками, Сводный план и сводный календарный график проекта.

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

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

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

На фазе 4 производится тестирование разработанного решения. При этом внимание фокусируется на его эксплуатации в реалистичной модели производственной среды (пилотное внедрение).

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

Результатами этой фазы являются: «Золотой» выпуск, Документация выпуска, Материалы поддержки решения, Результаты и инструментарий тестирования, Исходный и исполнимый код приложений, Проектная документация, Обзор вехи.

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

Главная веха 5 считается достигнутой, если решение начало давать заказчику ожидаемый результат, а команда может свернуть свою деятельность.

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

Следует сделать следующие замечания по этой модели ЖЦ. Длительность фаз не одинакова. Деятельность может выходить за рамки одной фазы. Наличие / отсутствие некоторых фаз определяется выполняемым проектом.

Таким образом, МСФ предлагает модель ЖЦ, основанную на распределении работ в команде проекта по фазам, а не на выделении процессов, как это делается в большинстве других подходов.

Процесс ICONIX (ICONIX Process)

Процесс ICONIX (ICONIX Process) - каркасный подход, предлагаемый фирмой ICONIX Software Engineering, Inc. Название этого подхода официально не является аббревиатурой, хотя и пишется прописными буквами.

В 1992 г. Д. Розенберг разработал подход, названный им Процесс ICONIX. В него были включены отобранные автором приемлемые методы из методик Г. Буча, Дж. Рамбо и А. Якобсона.

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

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

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

В качестве средств поддержки подхода используется инструментальное средство Enterprise Architect самой фирмы.

Основные особенности: 1. Упрощённое использование UML; 2. Высокая степень отслеживаемости; 3. Итеративность и инкрементность моделей.

Основы подхода

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

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

Разработка в рамках подхода выражается в виде трёх ключевых принципов: Снаружи внутрь, Изнутри наружу, Сверху вниз. Принцип «снаружи внутрь» определяет движение внутрь, исходя из требований пользователя, формализуемых в виде сценариев и прецедентов. Принцип «изнутри наружу» задаёт движение вовне, исходя из основных абстракций ПрО, образующих соответствующую модель. Принцип «сверху вниз» обозначает движение вниз - от высокоуровневых моделей к детализированному дизайну.

Жизненный цикл проекта

Модель ЖЦ для Процесса ICONIX отражает построение моделей во всех этапах ЖЦ, связанных с анализом и проектированием (рис.4.10).

В подходе выделено 4 этапа: 1. Анализ требований; 2. Предварительное проектирование; 3. Детализированное проектирование; 4. Реализация. Все этапы разграничены вехами, служащими для обзора работы, выполненной командой на соответствующих этапах.

Рис.4.10. Модель ЖЦ для Процесса ICONIX

На этапе 1 выполняются следующие действия:

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

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

- Определяются прецеденты в виде диаграмм прецедентов.

- Организуется группировка прецедентов в виде диаграммы пакетов.

- Размещаются функциональные требования к системе - в прецеденты и объекты ПрО.

Веха 1 позволяет установить, что:

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

- заказчик понимает идею системы и понятно отражает её в требованиях;

- команда способна создать дизайн системы по выделенным требованиям.

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

На этапе 2 выполняются следующие действия:

- Формируются описания прецедентов: основной ход событий прецедента («главный поток») и альтернативные ходы событий (редко используемые варианты и ошибочные ситуации).

- Выполняется анализ робастности. Для каждого прецедента:

определяется набор объектов, которые участвуют в выбранном сценарии,

строится диаграмма робастности с использованием стереотипов из UML Objectory (применяемых в подходе А. Якобсона),

обновляются диаграммы классов (добавляются новые объекты, а также новые атрибуты и ассоциации).

- Завершается обновление диаграмм классов. Это действие свидетельствует о завершении стадии анализа для проекта.

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

Веха 2 «Обзор предварительного дизайна» позволяет установить, что:

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

- модель ПрО соответствует диаграммам робастности (в частности, все объекты-сущности на диаграммах робастности представлены и в модели ПрО);

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

- можно проследить потоки данных между именованными экранными формами системы через классы-сущности и, возможно, к лежащему в основе системы хранилищу данных.

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

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

На этапе 3 выполняются следующие действия:

- «Размещается» поведение системы. Для каждого прецедента:

определяются сообщения, передаваемые объектами, сами объекты и соответствующие вызываемые методы,

строится диаграмма последовательности: слева указывается текст выполняемого сценария, справа - соответствующий дизайн (сама диаграмма),

обновляется диаграмма классов (добавляются новые атрибуты и операции).