8-software_engineering_process (1133548), страница 3
Текст из файла (страница 3)
автора). Это означает, что, в принципе, процессы жизненного циклапрограммного обеспечения могут быть “выстроены” (во времени) соответственно любой моделижизненного цикла. Основным источником знаний по процессам является стандарт IEEE/ISO/ГОСТ12207 “Information Technology – Software Lifecycle Processes” (основные элементы структуры этогостандарта рассматривается за рамками перевода и комментариев SWEBOK в самостоятельнойглаве, посвященной жизненному циклу).В рамках данных понятий жизненного цикла - “модель” и “процессы”, возможно говорить, чтосовокупность модели, процессов и практик определяет метод/методологию <поддержкижизненного цикла>.Стандарт IEEE 1074 “Standard for Developing Software Life Cycle Processes” предоставляет списокпроцессов и действий по разработке и сопровождению программного обеспечения, а также списокдействий по поддержке самого жизненного цикла, который может быть отображен на процессы иорганизован таким же образом, как и любая модель жизненного цикла.
Кроме того, этот стандартидентифицирует и связывает другие стандарты IEEE с действиями по поддержке процессовжизненного цикла. В принципе, стандарт IEEE 1074 может быть использован для построенияпроцессов, соответствующих любой модели жизненного цикла.SWEBOK отмечает два стандарта, связанных с процессами сопровождения программногообеспечения – IEEE 1219 “Standard for Software Maintenance” и ISO 14764 “Standard for SoftwareEngineering -Software Maintenance” (см. область знаний SWEBOK “Сопровождение программногообеспечения”).Другие важные стандарты, предоставляющие определение процессов, включают: IEEE 1540: Standard for Software Risk Management – управление рисками программногообеспечения IEEE 1517: Standard for Software Reuse Processes – процессы повторного использованияпрограммного обеспечения ISO/IEC 15939: Standard for Software Measurement Process – процесс измерений в областипрограммного обеспеченияВ ряде ситуаций процессы программной инженерии определяться принимая во вниманиеорганизационные процессы управления качеством.
ISO 9001 формулирует требования кпроцессам управления качеством, а ISO 9003 интерпретирует эти требования в отношенииорганизаций, занимающихся разработкой программного обеспечения (ISO/IEC 90003:2004,Software and Systems Engineering - Guidelines for the Application of ISO9001:2000 to ComputerSoftware).Некоторые процессы жизненного цикла придают особое значение быстрому вводу в эксплуатацию(rapid delivery) программных систем и глубокой вовлеченности пользователей <в процессразработки>. Такие процессы называют agile-методами – быстрыми, живыми, подвижными. К нимотносится, например, экстремальное программирование – eXtreme Programming (XP, см. работыКента Бека – Kent Beck). Отличительной особенностью этих методов является гибкость в вопросахпланирования, когда план проекта активно корректируется по мере продвижения к цели проекта.Другие процессы уделяют специальное внимание принятию решений на основе оценки рисков (см.работы Барри Боэма – Barry W.
Boehm).2.3 Нотации определения процесса (Notations for Process Definitions)Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru7Основы программной инженерии (по SWEBOK)Программная инженерия. Процесс программной инженерии.Процессы могут определяться на различных уровнях абстракции. В свою очередь, могут бытьопределены и различные элементы процессов – действия, продукты (артефакты) и ресурсы.
Приэтом, могут использоваться детальные фреймворки, структурирующие типы информации,требуемой для определения процессов.Существует ряд нотаций, используемых для определения процессов. Ключевое отличие междуними заключается в типах информации, которая определяется, контролируется и используетсятем или иным фреймворком. Инженеры должны иметь представление о следующих подходах:диаграммах потоков данных (data flow diagrams), в терминах целей процессов и получаемых на ихвыходе результатов (outcomes) (см. стандарт ISO 15504 “Information Technology - Software ProcessAssessment” - “SPICE”), как наборе процессов и их декомпозиции в работы и задачи,определенный на естественном языке (см. стандарт IEEE/ISO/ГОСТ 12207), диаграммахпереходов и состояний (statechart), SADT, IDEF0 и многих других.Хотя SWEBOK приводит расширенный список диаграмм/нотаций, вероятно, в силу своей“консервативности”, не упоминает, например, activity-диаграммы UML, хотя они могутиспользоваться в практике для описания бизнес-процессов, в частности, и для описанияпроцессов программной инженерии.
Ряд нотаций разработан и используется в рамках конкретных(частных) фреймворков/методологий, например, RUP. Кроме того, существует успешный опыт поиспользованию достаточно нотации BPMN – Business Process Management Notation для описанияпроцессов программной инженерии. Спецификация BPMN определяет графическоепредставление бизнес-процессов в форме диаграмм бизнес-процессов – Business Process Diagram(BPD). Первый стандарт BPMN был выпущен 3 мая 2004 года консорциумом The Business ProcessManagement Initiative – BPMI.org (http://www.bpmi.org). Предоставляя развитые выразительныесредства для определения процессов как комплекса взаимосвязанных действий, событий иартефактов, сгруппированных по участникам, BPMN позволяет достаточно легко сформировать врамках одной диаграммы BPD цельный взгляд на процессы.2.4 Адаптация процесса (Process Adaptation)Важно отметить, что предопределенные процессы, даже стандартизированные, должныадаптироваться в соответствии с локальными (конкретными) потребностями, например,организационным контекстом, размером проекта, регулирующих требованиях, индустриальныхпрактиках и корпоративной культурой.
Ряд стандартов, в первую очередь, IEEE/ISO/ГОСТ 12207 иISO 15504, содержат механизмы и рекомендации по процессу адаптации и егосовершенствованию.2.5 Автоматизация (Automation)Автоматизированные средства либо поддерживают сами работы по определению процессов(например, позволяя описывать процессы с использованием тех или иных диаграмм и нотаций)и/или предоставляют соответствующие руководства по определению процессов (например, RUP,EUP или MSF). В случаях, когда проводится процесс анализа, некоторые инструментыобеспечивают различные формы симуляции моделируемых (определяемых) процессов.3.
Оценка процесса (Process Assessment)Оценка процесса (process assessment) проводится с использованием соответствующих моделейоценки (assessment models) и методов оценки (assessment methods). Во многих случаях вместотермина “assessment” используется термин “appraisal” (подразумевая саму процедуру оценки,например, CMMI Appraisal). В свою очередь, термин “appraisal” заменяют на “capability evaluation”,когда говорят об оценке способностей/потенциальных возможностей, например, с цельюзаключения контракта/договора подряда на проведение соответствующих работ.Оценка процесса(-ов) может проводиться как неформально, подразумевая внутрикорпоративныеинициативы по повышению качества, и формально (то есть с получением аттестационногодокумента), в том числе, с привлечением внешних специалистов по оценке и, часто, с цельюподтверждения соответствующего качества/уровня зрелости процессов.3.1 Модели оценки процесса (Process Assessment Models)Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru8Основы программной инженерии (по SWEBOK)Программная инженерия.
Процесс программной инженерии.Модель оценки задает, что именно признается лучшими практиками оценки. Эти практики могуткасаться только “технических” работ программной инженерии (например, проектирования иликодирования), а могут иметь отношение и к вопросам управления, системной инженерии,управления персоналом и т.п.Стандарт ISO/IEC 15504 (SPICE) определяет типовую (exemplar) модель оценки и требованиясоответствия к другим моделям. В каждом конкретном случае используется та или инаясуществующая модель – CMM-SW, CMMI, Bootstrap*. Также имеются и другие модели, например,ISO 9000-3 (теперь именуемый как ISO 90003) “Software and Systems Engineering - Guidelines for theApplication of ISO9001:2000 to Computer Software”, являющаяся приложением общей моделикачества ISO 9001 “Quality Management Systems - Requirements” к программной инженерии.
Крометого, существуют частные модели, охватывающие, например, только вопросы документирования,проектирования и т.п.* В 1990 году стартовала европейская инициатива European Strategic Program for InformationTechnology (ESPRIT), целью которой было внедрение современных программных технологий вЕвропе. В основу инициативы легли работы Уотса Хампфри (Watts S. Humphrey) – идеолога CMMI,PSP (People Software Process) и многих других современных концепций программной инженериикак дисциплины. Результат этот инициативы был назван “Bootstrap” – “самонастройка”.
В то время,как модель CMM – Capability Maturity Model (в частности, CMM-SW – CMM for Software), а потом иCMMI, разрабатывались с учетом потребностей крупных государственных структур США (в первуюочередь, министерства обороны) и их подрядчиков, модель Bootstrap изначально былаориентирована на малые и средние коммерческие компании, с определенным акцентом наиндивидуальные практики.Также и в системной инженерии существуют модели зрелости, применимые в отношениипрограммного обеспечения, когда программы являются частью системы.SWEBOK отмечает, что ряд моделей применим к небольшим организациям.Существуют две основных архитектуры моделей оценки: непрерывная (continuous) и этапная(staged).
Отличия между ними заключаются во взгляде на порядок оценки процессов. Выборсоответствующей архитектуры и модели оценки в конкретной организации должен базироватьсяна ее целях и потребностях (например, необходимости совершенствования тех или иныхпроцессных областей или официального подтверждения внешним асессором достиженияорганизацией четвертого уровня зрелости всего процесса программной инженерии по CMMI).3.2 Методы оценки процесса (Process Assessment Methods)Для надлежащего проведения оценки соответствующие методы <оценки> позволяют получитьколичественные параметры, характеризующие возможности оцениваемого процесса (или зрелостиорганизации, в целом).Например, метод CBA-IPI (CMM-Based Appraisals for Internal Process Improvement) фокусируется насовершенствовании процесса внутри организации, а метод SCE (Software Capability Evaluation)касается процессов у подрядчиков*. Требования в обоих типах методов отражают те лучшиепрактики оценки, которые описаны в стандарте ISO 15504.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
