commit ac26fd08856eb09fe1babd88852586d46886c009 from: Mike Voznesensky via: Sergey Bronnikov date: Tue Aug 27 14:15:48 2024 UTC Removed angle brackets commit - 0f568d073ef5dd305ae624595c9691a0ada6fabd commit + ac26fd08856eb09fe1babd88852586d46886c009 blob - d064c732c739615c9a4d403d24a6d010c3c8956c blob + b21b56a9c8eefffa0a0c13212009f3af5bd76303 --- 10_software_quality.md +++ 10_software_quality.md @@ -44,9 +44,9 @@ Mean Time To Failure, то есть среднее в и т.п.). В какой-то степени, “приемлемое качество” можно сравнивать с уровнем обслуживания в рамках заданного SLA – Service Level Agreement, давно уже принятого на вооружение в телекоммуникационной индустрии. Таким образом, -приемлемое качество может рассматриваться как <количественно выраженный> +приемлемое качество может рассматриваться как количественно выраженный компромисс между заказчиком и исполнителем в отношении характеристик продукта, -создаваемого исполнителем в интересах <решения задач> заказчика с учетом других +создаваемого исполнителем в интересах решения задач заказчика с учетом других ограничений проекта (в частности, стоимостью, что часто именуется как “cost of quality” – “стоимость качества”). Можно сказать, что такой взгляд может в какой-то степени рассматриваться как расширение определения ISO 9001 с учетом @@ -54,7 +54,7 @@ quality” – “стоимость качества отношении характеристик качества. Данная глава (область знаний) рассматривает вопросы качества программного -обеспечения, выходя за рамки <отдельных> процессов жизненного цикла. Качество +обеспечения, выходя за рамки отдельных процессов жизненного цикла. Качество программного обеспечения является постоянным объектом заботы программной инженерии и обсуждается во многих областях знаний (что вполне обосновано, если учесть поистине катастрофический уровень проваленных проектов и @@ -71,7 +71,7 @@ quality” – “стоимость качества Согласие, достигнутое по требованиям к качеству (в оригинале - quality requirements), наравне с четким доведением до инженеров того, что составляет -качество <получаемого продукта>, требуют обсуждения и формального определения +качество получаемого продукта, требуют обсуждения и формального определения многих аспектов качества. Инженеры должны понимать смысл, вкладываемый в концепцию качества, @@ -81,28 +81,28 @@ requirements), наравне с четким дове Важной идеей является то, что программные требования определяют требуемые характеристики качества программного обеспечения, а также влияют на методы количественной оценки и сформулированные для оценки этих характеристик -<соответствующие> критерии приемки. +соответствующие критерии приемки. ### Культура и этика программной инженерии (Software Engineering Culture and Ethics) Ожидается, что инженеры по программному обеспечению воспринимают вопросы -качества программного обеспечения как часть своей <профессиональной> культуры. +качества программного обеспечения как часть своей профессиональной культуры. SWEBOK дает ссылки на источники, описывающие здоровую культуру программной инженерии. Этические аспекты могут играть значительную роль в обеспечении качества -программного обеспечения, культуре и отношении инженеров <к своей работе>. IEEE +программного обеспечения, культуре и отношении инженеров к своей работе. IEEE Computer Society и ACM разработали кодекс этики (“моральный кодекс” – code of ethics) и профессиональной практики, основанный на восьми принципах, помогающих -инженерам укрепить их отношение к качеству и независимость <в решении вопросов -обеспечения достойного качества создаваемых программных продуктов> в их +инженерам укрепить их отношение к качеству и независимость в решении вопросов +обеспечения достойного качества создаваемых программных продуктов в их повседневной работе. ### Значение и стоимость качества (Value and Costs of Quality) Понятие “качество”, на самом деле, не столь очевидно и просто, как это может показаться на первый взгляд. Для любого инженерного продукта существует -множество <интерпретаций> качества, в зависимости от конкретной “системы +множество интерпретаций качества, в зависимости от конкретной “системы координат” (в оригинале – “перспективы”). Множество этих точек зрения необходимо обсудить и определить на этапе выработки требований к программному продукту. Характеристики качества могут требоваться в той или иной степени, @@ -112,7 +112,7 @@ ethics) и профессиональной практ обеспечение качества, как достижение совершенства). Стоимость качества (cost of quality) может быть дифференцирована на стоимость -предупреждения <дефектов> (prevention cost), стоимость оценки (appraisal cost), +предупреждения дефектов (prevention cost), стоимость оценки (appraisal cost), стоимость внутренних (internal failure cost), а также внешних сбоев (external failure cost). @@ -133,7 +133,7 @@ failure cost). такого рода решений должно приниматься процессе работы с требованиями (см. область знаний SWEBOK “Программные требования”), однако эти вопросы могут (и должны) подниматься на протяжении всего жизненного цикла программного -обеспечения. Не существует каких-то <“стандартных”> правил того, как именно +обеспечения. Не существует каких-то “стандартных” правил того, как именно необходимо принимать такие решения. Однако, инженеры должны быть способны представить различные альтернативы (в достижении различного уровня качества) и их стоимость. Здесь SWEBOK приводит некоторые источники, в которых более @@ -144,7 +144,7 @@ failure cost). В различных источниках (таксономиях и моделях) терминология характеристик качества программного обеспечения отличается. Каждая модель включает различное -число уровней иерархии и общее число <”распознанных”> характеристик качества. +число уровней иерархии и общее число ”распознанных” характеристик качества. Различные авторы создали разные модели качества со своим набором характеристик и атрибутов (в частности, Барри Боэм, автор спиральной модели жизненного цикла разработки программного обеспечения, которая рассматривается в отдельной @@ -255,8 +255,8 @@ quality”. Эти концепции основыва продуктов и получению всех необходимых данных. Кроме этого, разрабатываемая программа совершенствования (improvement program, обычно является целевой и охватывает работу подразделения или организации, в целом) детально -идентифицирует все действия и проекты по улучшению <отдельных аспектов -деятельности> в рамках определенного периода времени, за который такие проекты +идентифицирует все действия и проекты по улучшению отдельных аспектов +деятельности в рамках определенного периода времени, за который такие проекты можно осуществить с успешным решением соответствующих задач. При этом, поддержка менеджмента означает, что все проекты по улучшению обладают достаточными ресурсами для достижением поставленных целей. Поддержка @@ -330,12 +330,12 @@ SQM может использоваться для о полученной практики и уже произведенные продукты. Однако, они играют главную роль на стадии планирования, являясь проактивными как процессы и процедуры, необходимые для достижения характеристик и уровня качества, востребованных -заинтересованными лицами <проекта> программного обеспечения. +заинтересованными лицами проекта программного обеспечения. Управление рисками также может играть значительную роль для выпуска качественного программного обеспечения. Включение “регулярного” (как постоянно действующего, а не периодического; в оригинале – disciplined) анализа рисков и -<соответствующих> техник управления <рисками> в процессы жизненного цикла +соответствующих техник управления рисками в процессы жизненного цикла программного обеспечения может увеличить потенциал для производства качественного продукта. Более подробную информацию по управлению рисками можно найти в области знаний “Управление программной инженерией”. @@ -344,14 +344,14 @@ SQM может использоваться для о Процессы SQA обеспечивают подтверждение того, что программные продукты и процессы жизненного цикла проекта соответствуют заданным требованиям. Такое -подтверждение проводится на основе планирования (planning), постановки <работ> +подтверждение проводится на основе планирования (planning), постановки работ (enacting) и исполнения (performing) набора действий, направленных на то, чтобы качество стало неотъемлемой частью программного обеспечения (см. выше определения качества). Такой взгляд подразумевает ясное и точное формулирование проблемы, а также то, что определены и четко выражены (полны и однозначно -интерпретируемы) требования к соответствующему <программному> решению. SQA +интерпретируемы) требования к соответствующему программному решению. SQA добивается обеспечения качества в процессе разработки и сопровождения за счет -выполнения различных действий на всех этапах <жизненного цикла>, что позволяет +выполнения различных действий на всех этапах жизненного цикла, что позволяет идентифицировать проблемы еще на ранних стадиях, которые практически неизбежны в любой сложной деятельности. @@ -382,7 +382,7 @@ SQA-план определяет средства, к цели качества были четко определены и понимаемы (а также, однозначно интерпретируемы, что является обязательным условием любых целей и соответствующих требований). Это, в обязательном порядке, должно быть отражено -в соответствующих планах управления <проектом>, разработки и сопровождения. +в соответствующих планах управления проектом, разработки и сопровождения. Подробности можно найти в стандарте IEEE 730-02 “IEEE Standard for Software Quality Assurance Plans”. @@ -402,17 +402,17 @@ Quality Assurance Plans”. проектов, а не SQA-плана), тренинги, а также формирование отчетности и документации, относящиеся к вопросам SQA. Кроме того, SQA-план касается и вопросов работ по обеспечению качества, относящихся к другим типам -деятельности, описанным в <различных> планах по созданию программного +деятельности, описанным в различных планах по созданию программного обеспечения, к которым также относятся поставка, установка, обслуживание (поддержка и сопровождение) заказных и/или тиражируемых/готовых программных решений (commercial off-the-shelf, COTS), необходимых для данного проекта программного обеспечения. Наконец, SQA-план может содержать необходимые для обеспечения качества критерии приемки программного обеспечения и действия по -формированию отчетности и управлению <и контролю над> работами. +формированию отчетности и управлению и контролю над работами. ### Проверка (верификация) и аттестация (Verification and Validation, V&V) -С целью краткости <изложения> (что, не мешало их детализировать достаточным +С целью краткости изложения (что, не мешало их детализировать достаточным образом, в виде соответствующих "подтем" в рамках формата SWEBOK, так как, будучи тесно связанными и взаимодополняющими, проверка и аттестация все же обладают и самостоятельным содержанием), проверка (верификация) и аттестация – @@ -435,7 +435,7 @@ V&V: “Проверка и аттестация пр V&V напрямую адресуется вопросам качества программного обеспечения и использует соответствующие техники тестирования для обнаружения тех или иных дефектов. V&V может применяться для промежуточных продуктов, однако, в том объеме, который -соответствует промежуточным “шагам” <соответствующих> процессов жизненного +соответствует промежуточным “шагам” соответствующих процессов жизненного цикла. Процесс V&V определяет в какой степени продукт (результат) тех или иных работ @@ -457,7 +457,7 @@ V&V напрямую адресуется вопрос Целью планирования V&V является обеспечение процессов верификации и аттестации необходимыми ресурсами, четкое назначение ролей и обязанностей. Получаемый план -V&V документирует и <детально> описывает различные ресурсы, роли и действия, а +V&V документирует и детально описывает различные ресурсы, роли и действия, а также используемые техники и инструменты. Понимание различных целей каждого действия в рамках V&V может помочь в точном планировании техник и ресурсов (включая, финансовые), необходимых для достижения заданных целей. Стандарты @@ -494,7 +494,7 @@ Software Verification and Validation Plans” (Appendi #### Управленческие оценки (Management Reviews) “Назначение управленческих оценок состоит в отслеживании развития -<проекта/продукта>, определения статуса планов и расписаний, утверждения +проекта/продукта, определения статуса планов и расписаний, утверждения требования и распределения ресурсов, или оценки эффективности управленческих подходов, используемых для достижения поставленных целей.” - IEEE 1028-97 “IEEE Standard for Software Reviews”. Управленческие оценки поддерживают принятие @@ -505,7 +505,7 @@ Standard for Software Reviews”. Управленче будучи фиксируемы в форме отчетов аудита, отчетов о состоянии (развитии), V&V-отчетов, а также различных типов планов – управления рисками, проекта/проектного управления, конфигурационного управления, безопасности -<использования> программного обеспечения (safety), оценки рисков и т.п. +использования программного обеспечения (safety), оценки рисков и т.п. Информация, связанная с данными вопросами, также представлена в областях знаний “Управление программной инженерией” и “Конфигурационное управление”. @@ -528,9 +528,9 @@ IEEE 1028-97 “IEEE Standard for Software Reviews”. - Списка проблем (вопросов), ассоциированных с продуктом - Процедуры технической оценки -Команда <технической оценки> следует заданной процедуре оценки. +Команда технической оценки следует заданной процедуре оценки. Квалифицированные (с технической точки зрения) лица представляют обзор продукта -(представляя команду разработки). Исследование <продукта> проводится в течение +(представляя команду разработки). Исследование продукта проводится в течение одной и более встреч (между теми, кто представляет продукт и теми, кто провoдит оценку). Техническая оценка завершается после того, как выполнены все предписанные действия по исследованию продукта. @@ -565,17 +565,17 @@ IEEE 1028-97 “IEEE Standard for Software Reviews”. продукту, в целом, рассматривая в последнем случае только один его аспект, например, интерфейсы. Любая найденная аномалия должна документироваться, а информация передаваться лидеру инспекции. В процессе инспекции лидер руководит -сессией <инспекции> и проверяет, что все <члены команды> подготовились к +сессией инспекции и проверяет, что все члены команды подготовились к инспектированию. Общим инструментом, используемым при инспектировании, является проверочный лист (checklist), содержащий аномалии и вопросы, связанные с -аспектами <программного продукта>, вызывающими интерес. Результирующий лист +аспектами программного продукта, вызывающими интерес. Результирующий лист часто классифицирует аномалии (см. стандарт IEEE 1044-93 “IEEE Standard for the Classification of Software Anomalies”) и оценивается командой с точки зрения его завершенности и точности. Решение о завершении инспекции принимается в соответствии с одним (любым) из трех критериев: -- Принятие <продукта> с отсутствием либо малой необходимостью переработки -- Принятие <продукта> с проверкой переработанных фрагментов +- Принятие продукта с отсутствием либо малой необходимостью переработки +- Принятие продукта с проверкой переработанных фрагментов - Необходимость повторной инспекции - Инспекционные встречи занимают, обычно, несколько часов, в отличие от технической оценки и аудита, предполагающих, в большинстве случаев, больший @@ -609,7 +609,7 @@ Classification of Software Anomalies”) и оцени (another auditor), регистратор (recorder) и инициатор (initiator). В аудите принимает участие представитель оцениваемой организации/организационной единицы. В результате аудита идентифицируются случаи несоответствия и -формируется отчет, необходимый команде <разработки> для принятия корректирующих +формируется отчет, необходимый команде разработки для принятия корректирующих действий. При том, что существуют различные формальные названия (и классификации) оценок @@ -627,7 +627,7 @@ Classification of Software Anomalies”) и оцени различные факторы, среди которых: - Область применения системы, в которой будет работать программное обеспечение -(критичное для безопасности <людей>), критичное для бизнеса и т.п.) +(критичное для безопасности людей), критичное для бизнеса и т.п.) - Системные и программные требования - Какие компоненты используются в системе – коммерческие (внешние) или стандартные (внутренние) @@ -648,7 +648,7 @@ Classification of Software Anomalies”) и оцени #### Гарантоспособность (Dependability) -(Гарантоспособость – гарантия <высокой> надежности, защищенности от сбоев) +(Гарантоспособость – гарантия высокой надежности, защищенности от сбоев) В случаях, когда сбой системы может привести к крайне тяжелым последствиям (такие системы иногда называют в англоязычных источниках “high confidence” или @@ -656,7 +656,7 @@ Classification of Software Anomalies”) и оцени “системы повышенной надежности”, “высокой доступности” и т.п.), общая (совокупная) гарантоспособность системы (как сочетания аппаратной части, программного обеспечения и человека) является главным и приоритетным -требованием качества, по отношению к основной функциональности <системы>. +требованием качества, по отношению к основной функциональности системы. Гарантоспособность (dependability) программного обеспечения включает такие характеристики, как защищенность от сбоев (fault-tolerance), безопасность использования (safety – безопасность в контексте приемлемого риска для здоровья @@ -686,7 +686,7 @@ Quality Model”). опасностей (в контексте безопасности использования, safety) и анализа угроз (в информационной безопасности, security). История сбоев аналогичных систем может также помочь в идентификации наиболее полезных техник, направленных на -обнаружение сбоев и <всесторонней> оценки качества программного обеспечения. +обнаружение сбоев и всесторонней оценки качества программного обеспечения. Уровни целостности (например, градации целостности) предлагаются, в частности, стандартом IEEE 1012-98 “IEEE Standard for Software Reviews”. @@ -742,10 +742,10 @@ SQM обеспечивает сбор информац выглядят следующим образом: - Ошибка (error): “Отличие … между корректным результатом и вычисленным -результатом < полученным с использованием программного обеспечения>” +результатом полученным с использованием программного обеспечения” - Недостаток (fault): “Некорректный шаг, процесс или определение данных в компьютерной программе” -- Сбой (failure): “<Некорректный> результат, полученный в результате +- Сбой (failure): “Некорректный результат, полученный в результате недостатка” - Человеческая/пользовательская ошибка (mistake): “Действие человека, приведшее к некорректному результату” @@ -763,7 +763,7 @@ SQM обеспечивает сбор информац действия по удалению дефектов из исследуемого продукта. Однако, этим дело не ограничивается. Есть и другие возможные действия, позволяющие получить полную отдачу от результатов выполнения соответствующих SQM-работ. Среди них – анализ -и подведение итогов (резюмирование) <по обнаруженным несоответствиям/дефектам>, +и подведение итогов (резюмирование) по обнаруженным несоответствиям/дефектам, использование техник количественной оценки (получение метрик) для улучшения продукта и процесса, отслеживание дефектов и удаления их из системы (с управленческим и техническим контролем проведения необходимых корректирующих @@ -803,7 +803,7 @@ request) и могут, впоследствии, за #### Статические техники (Static techniques) -Статические техники предполагают <детальное> исследование (examination) +Статические техники предполагают детальное исследование (examination) проектной документации, программного обеспечения и другой информации о программном продукте без его исполнения. Эти техники могут включать другие, рассматриваемые ниже, действия по “коллективной” оценке (см. 3.3.2) или @@ -834,7 +834,7 @@ request) и могут, впоследствии, за относится различного рода листы проверки (checklists) и результаты аналитических техник (рассматриваются ниже) и работ по тестированию. Данные техники рассматриваются, например, в стандарте 12207 при обсуждении оценки -( review) и аудита (audit). SWEBOK приводит и другие полезные источники, +(review) и аудита (audit). SWEBOK приводит и другие полезные источники, в которых можно найти дополнительную информацию по обсуждаемому вопросу. #### Аналитические техники (Analytical techniques) @@ -848,7 +848,7 @@ request) и могут, впоследствии, за рода суждение является крайне консервативным и ограниченным. Особенно это заметно в контексте широкого (и достаточно успешного) применения Agile-методик и подходов, в которых individuals and interactions (см.первое положение The -Agile Manifesto) предполагает <непосредственное> общение и постоянное +Agile Manifesto) предполагает непосредственное общение и постоянное взаимодействие членов команды (включая представителей заказчика – см. третье положение Agile Manifesto - customer collaboration). В частности, Agile-взгляд на SQM, вероятно, требует расширения вариантов форм оценки дополнительными @@ -889,7 +889,7 @@ analysis) и алгоритмический анали говоря, мало связано с формальными методами – это естественный путь достижения приемлемого качества при минимизации затрат). Чаще всего они используются для верификации особо важных частей критически-важных систем, например, конкретных -требований <информационной> безопасности и надежности. +требований информационной безопасности и надежности. #### Динамические техники (Dynamic techniques) @@ -909,7 +909,7 @@ execution, часто предполагает исп роли человека в организации, он может принимать и применять одни и те же техники по-разному. -В зависимости от организации <ведения> проекта, определенные работы по +В зависимости от организации ведения проекта, определенные работы по тестированию могут выполняться при разработке программных систем в SQA и V&V процессах. В силу того, что план SQM адресуется вопросам тестирования, данная тема включает некоторые комментарии по тестированию. В свою очередь, область @@ -920,17 +920,17 @@ execution, часто предполагает исп #### Тестирование (Testing) -Процессы подтверждения <качества>, описанные в SQA и V&V <планах>, исследуют и +Процессы подтверждения качества, описанные в SQA и V&V планах, исследуют и оценивают любой выходной продукт (включая промежуточный и конечный), связанный со спецификацией требований к программному обеспечению, на предмет трассируемости (traceability), согласованности (consistency), полноты/завершенности (completeness), корректности (correctness) и -непосредственно выполнения <требований> (performance). Такое подтверждение +непосредственно выполнения требований (performance). Такое подтверждение также охватывает любые выходные артефакты процессов разработки и сопровождения, сбора, анализа и количественной оценки результатов. SQA-деятельность обеспечивает гарантию того, что соответствующие (необходимые в заданном контексте проекта) типы тестов спланированы, разработаны и реализованы, а V&V – -разработку планов тестов, стратегий, сценариев и процедур <тестирования>. +разработку планов тестов, стратегий, сценариев и процедур тестирования. Вопросы тестирования детально обсуждаются в области знаний “Тестирование”. Два типа тестирования следуют задачам, задаваемым SQA и V&V, потому как на них @@ -948,7 +948,7 @@ Adoption of International Standard IDO/IEC12119:1994(E Иногда, независимые V&V-организации могут требовать возможности мониторинга процесса тестирования и, в определенных случаях, заверять (или, чаще, -документировать/фиксировать) реальное выполнение <тестов> на предмет их +документировать/фиксировать) реальное выполнение тестов на предмет их проведения в соответствии с заданными процедурами. С другой стороны, может быть сделано обращение к V&V может быть направлено на оценку и самого тестирования: достаточности планов и процедур, соответствия и точности результатов. @@ -975,7 +975,7 @@ Adoption of International Standard IDO/IEC12119:1994(E проблемных аспектов и узких мест в процессах. Метрики являются инструментом оценки качества своей работы самими инженерами – как в целях, определенных SQA, так и с точки зрения более долгосрочного процесса совершенствования -<достигаемого> качества. +достигаемого качества. С увеличением внутренней сложности, изощренности программного обеспечения, вопросы качества выходят далеко за рамки констатации факта – работает или не @@ -988,7 +988,7 @@ Adoption of International Standard IDO/IEC12119:1994(E модели надежности и сравнение с образцами (эталонами, принятыми в качестве примеров определенного уровня качества – benchmarks). -Стоимость процесса SQM является одним из <проблемных> вопросов, который всегда +Стоимость процесса SQM является одним из проблемных вопросов, который всегда всплывает в процессе принятия решения о том, как будет организован проект (проектные работы). Часто, используются общие (generic) модели стоимости, основанные на определении того, когда именно дефект обнаружен и как много @@ -1007,7 +1007,7 @@ Adoption of International Standard IDO/IEC12119:1994(E Хотя, как количественные оценки (в данном случае речь идет о результатах оценок, а не о процессе измерений) характеристик качества могут полезны сами по себе (например, число неудовлетворенных требований и пропорция таких -требований), могут <эффективно> применяться математические и графические +требований), могут эффективно применяться математические и графические техники, облегчающие интерпретацию значений метрик. Такие техники вполне естественно классифицируются, например, следующим образом: @@ -1022,7 +1022,7 @@ Adoption of International Standard IDO/IEC12119:1994(E предоставляют “снимок” наиболее проблемных областей исследуемого программного продукта (и, кстати, то же часто верно и в отношении процессов). Результирующие графики и диаграммы визуально помогают лицам, принимающим решения, в -определении аспектов, на которых необходимо сфокусировать ресурсы <проекта>. +определении аспектов, на которых необходимо сфокусировать ресурсы проекта. Результаты анализа тенденций могут демонстрировать, что нарушается расписание, например, при тестировании; или что сбои определенных классов становятся все более частыми до тех пор, пока не предпринимаются корректирующие действия в @@ -1037,14 +1037,14 @@ SWEBOK предоставляет ссылки на и рассматриваются аспекты анализа дефектов (defect analysis), количественной оценки возникновения дефектов и последующего применения статистических методов для формирования понимания наиболее часто встречающихся типов дефектов и -отвечая на вопрос соответствующей оценки плотности дефектов <различных типов>. +отвечая на вопрос соответствующей оценки плотности дефектов различных типов. Они могут, также, помочь в понимании тенденций и оценке того, насколько хорошо работают техники обнаружения дефектов и насколько успешно развиваются (как в плане выполнения, так и в контексте совершенствования) процессы разработки и сопровождения. Оценка покрытия тестами (test coverage) облегчает формирование ожиданий в отношении оставшегося объема тестирования и предсказании возможного -количества дефектов, которые будут еще обнаружены <до окончания процесса -тестирования>. На основе этих методов количественной оценки могут быть +количества дефектов, которые будут еще обнаружены до окончания процесса +тестирования. На основе этих методов количественной оценки могут быть сформированы, так называемые профили дефектов (defect profiles) для конкретных прикладных областей (application domains). В дальнейшем, для будущих программных систем в данной организации, такие профили могут направлять blob - 50f296d2f36e35e97071af397c4ad79672eae31a blob + b59eabc79ca26ddb193b1fe6ebdf1e99242f895b --- 1_software_requirements.md +++ 1_software_requirements.md @@ -222,11 +222,11 @@ agile-техниках, например, FDD – Feat Вигерс, описывает feature как “множество логически связанных функциональных требований, которые предоставляют определенные возможности для пользователя и -удовлетворяют бизнес-целям <организации>”. С точки зрения маркетинга -программного обеспечения, как отмечает Вигерс, feature это «группа требований, +удовлетворяют бизнес-целям организации”. С точки зрения маркетинга +программного обеспечения, как отмечает Вигерс, feature это «группа требований, узнаваемая заинтересованными лицами, которые вовлечены в процесс принятия -решения по приобретению ПО – это список <отличительных особенностей или -возможностей, характеристик>, присутствующий в описании продукта». В то же +решения по приобретению ПО – это список отличительных особенностей или +возможностей, характеристик, присутствующий в описании продукта». В то же время, Леффингвелл и Видриг (D.Leffingwell, D. Widrig, Managing Software Requirements: A Use Case Approach, Second Edition, 2003) определяют feature как “сервисы, которые оказывает система для удовлетворения одной или более @@ -307,7 +307,7 @@ kshell (популярной командной обо В качестве примера можно привести реальное требование, присутствующее в реальном проекте по электронному документообороту: “Система должна производить -поиск документов <определенного вида> за время, не превышающее 5 секунд”. Это +поиск документов определенного вида за время, не превышающее 5 секунд”. Это типичное требование с количественной оценкой, в котором определена верхняя граница диапазона времени, за которое должен быть осуществлен поиск документов. Несомненно, этот атрибут качества системы существует в контексте определенного @@ -323,7 +323,7 @@ kshell (популярной командной обо Данное разделение базируется на определении “системы”, данном INCOSE (International Council on Systems Engineering) “комбинация -взаимодействующих элементов <созданная> для достижения определенных целей; +взаимодействующих элементов созданная для достижения определенных целей; может включать аппаратные средства, программное обеспечение, встроенное ПО, другие средства, людей, информацию, техники (подходы), службы и другие поддерживающие элементы”; таким образом, подразумевается, что система является @@ -418,7 +418,7 @@ kshell (популярной командной обо обладают “заказчиками” в понимании персонификации тех, кто “заказывает разработку. В то же самое время, лица, отвечающие за маркетинг, нуждаются в идентификации потребностей и обращению к тем, кто может играть роль -<квалифицированных> “представителей” потребителей; +квалифицированных “представителей” потребителей; - Регуляторы (Regulators): многие области применения (“домены”) являются регулируемыми, например, телекоммуникации или банковский сектор. Программное @@ -793,8 +793,8 @@ Requirements for Enterprise-Reference Architectures an ### Определение системы (System Definition Document) Данный документ, часто называемый как “спецификация пользовательских -требований” (user requirements specification) или “концепция” (concept ), описывает системные требования. Содержание документа определяет +требований” (user requirements specification) или “концепция” (concept of +operations), описывает системные требования. Содержание документа определяет высокоуровневые требования, часто – стратегические цели, для достижения которых создается программная система. Принципиальным моментом является то, что такой документ описывает требования к системе с точки зрения области применения - @@ -1171,7 +1171,7 @@ points для оценки масштабов функ Engineering Process). В дополнение к практическим соображениям, представленным в SWEBOK, на фоне -общей тенденции разработки моделей <оценки> зрелости, стоит отметить, что +общей тенденции разработки моделей оценки зрелости, стоит отметить, что существуют определенные работы и по созданию различных моделей зрелости требований. Например, наиболее популярная модель зрелости в индустрии программного обеспечения – CMMI включает разный объем и содержание работ по blob - bdc5ac227824cb28fb126dd188f87fc415273ec7 blob + ddc53a82070c25d983e0b8c26308aabea83517fb --- 2_software_design.md +++ 2_software_design.md @@ -80,7 +80,7 @@ FP-дизайн. I-дизайн в большей ст используемые представления и решения. Например, архитектурный фреймворк – TOGAF [TOGAF, 2003], разработанный и развиваемый консорциумом The Open Group (www.opengroup.org), предлагает -следующие <возможные> цели (goals): +следующие возможные цели (goals): - Улучшение и повышение продуктивности бизнес-процессов - Уменьшение затрат @@ -90,7 +90,7 @@ FP-дизайн. I-дизайн в большей ст - Повышение эффективности ИТ-организации - Повышение продуктивности работы пользователей - Повышение интероперабельности (возможности и прозрачности взаимодействия) -- Уменьшение стоимости <поддержки> жизненного цикла +- Уменьшение стоимости поддержки жизненного цикла - Улучшение характеристик безопасности - Повышение управляемости @@ -431,7 +431,7 @@ mediator, memento, observer, state, strategy, template Также известные как метрики. Могут быть использованы для количественной оценки ожиданий в отношении различных аспектов конкретного дизайна, например, размера -<проекта>, структуры (ее сложности) или качества (например, в контексте +проекта, структуры (ее сложности) или качества (например, в контексте требований, предъявляемых к производительности). Чаще всего, все метрики разделяют по двум категориям: @@ -472,13 +472,13 @@ Collaborator или CRC Card (CRC по свое при компонентов, реализующих не функциональность, но обеспечивающих взаимосвязь функциональных компонентов между собой и с “внешним миром”); - *Диаграммы классов и объектов (Class and object diagrams)*: используются для -представления набора классов и <статических> связей между ними (например, +представления набора классов и статических связей между ними (например, наследования); - *Диаграммы компонентов или компонентные диаграммы (Component diagrams)*: в определенной степени аналогичны диаграммам классов, однако, в силу специфики концепции или понятия компонента[^2_2], обычно, представляются в другой визуальной форме; -- *Карточки <функциональной> ответственности и связей класса (Class +- *Карточки функциональной ответственности и связей класса (Class responsibility collaborator card, CRC)*: используются для обозначения имени класса, его ответственности (то есть, что он должен делать) и других сущностей (классов, компонентов, актёров/ролей и т.п.), с которыми он связан; часто их @@ -501,7 +501,7 @@ IDL)*: языки, подобные языкам пр [^2_2]: Здесь необходимо отметить различие в понятиях класса (или объекта) и компонента: компонент рассматривается как физически реализуемый элемент -программного обеспечения, несущий <в определенной степени> самодостаточную +программного обеспечения, несущий в определенной степени самодостаточную логику и реализуемый как конгломерат интерфейса и его реализации (часто, в виде комплекса классов); @@ -521,7 +521,7 @@ IDL)*: языки, подобные языкам пр - *Диаграммы потоков данных (Data flow diagrams, DFD)*: описывают потоки данных внутри набора процессов (не в терминах процессов операционной среды, но в понимании обмена информацией в бизнес-контексте); -- *Таблицы и диаграммы <принятия> решений (Decision tables and diagrams)*: +- *Таблицы и диаграммы принятия решений (Decision tables and diagrams)*: используются для представления сложных комбинаций условий и действий (операций); - *Блок-схемы и структурированные блок-схемы (Flowcharts and structured @@ -591,7 +591,7 @@ languages, PDL)*: языки, используемые мета-информации, например, с применением технологии отражения (reflection). Хотя корни объектно-ориентированного проектирования лежат в абстракции данных (к которым добавлены поведенческие характеристики), так называемый -responsibility-driven design или проектирование на основе <функциональной> +responsibility-driven design или проектирование на основе функциональной ответственности по SWEBOK[^2_3] может рассматриваться как альтернатива объектно-ориентированному проектированию. blob - b4d02ad105bdcc99724e4fd1f7be67f28f2897dd blob + 89a70dfc34a7e3b94a9527aa15b39278e4aa1364 --- 3_software_construction.md +++ 3_software_construction.md @@ -140,7 +140,7 @@ management), причем, в той степени, Стандарты, которые напрямую применяются при конструировании, включают: - коммуникационные методы (например, стандарты форматов документов и -<оформления> содержания) +оформления содержания) - языки программирования и соответствующие стили кодирования (например, Java Language Specification, являющийся частью стандартной документации JDK – Java Development Kit и Java Style Guide, предлагающий общий стиль кодирования для @@ -494,8 +494,8 @@ Technology – Software Lifecycle Process – Reuse Pr Задачи, связанные с повторным использованием в процессе конструирования и тестирования, включают: -- выбор единиц (units), баз данных тестовых процедур, данных <полученных в -результате> тестов и самих тестов, подлежащих повторному использованию +- выбор единиц (units), баз данных тестовых процедур, данных полученных в +результате тестов и самих тестов, подлежащих повторному использованию - оценку потенциала повторного использования кода и тестов - отслеживание информации и создание отчетности по повторному использованию в новом коде, тестовых процедурах и данных, полученных в результате тестов. blob - 56b654df2bded15cdd92b073a88083a3b6953188 blob + d2b3ccfd4e17c4819634f9275809f437eb2e49de --- 4_software_testing.md +++ 4_software_testing.md @@ -395,11 +395,11 @@ TDD. Насколько это верно, завис ### Техники, базирующиеся на спецификации (Specification-based techniques) -#### Эквивалентное разделение <приложения> (Equivalence partitioning) +#### Эквивалентное разделение приложения (Equivalence partitioning) Рассматриваемая область приложения разделяется на коллекцию наборов или эквивалентных классов, которые считаются эквивалентными с точки зрения -рассматриваемых связей и характеристик <спецификации>. Репрезентативный набор +рассматриваемых связей и характеристик спецификации. Репрезентативный набор тестов (иногда – только один тест) формируется из тестов эквивалентных классов (или наборов классов). blob - 1b4ef61388db73757127a0b968341e287504c2e3 blob + d19ed2b21f88f0afb25ddba94886c69f2756dd26 --- 5_software_maintenance.md +++ 5_software_maintenance.md @@ -109,9 +109,9 @@ for Software Maintenance (IEEE 1219) как модиф В свою очередь, стандарт жизненного цикла 12207 (IEEE, ISO/IEC, ГОСТ Р ИСО/МЭК) позиционирует сопровождение как один из главных процессов жизненного цикла. Этот стандарт описывает сопровождение как процесс модификации программного -продукта в части его кода и документации для решения возникающих проблем <при -эксплуатации> или реализации потребностей в улучшениях <тех или иных -характеристик продукта>. Задача состоит в модификации продукта при условии +продукта в части его кода и документации для решения возникающих проблем при +эксплуатации или реализации потребностей в улучшениях тех или иных +характеристик продукта. Задача состоит в модификации продукта при условии сохранения его целостности. Международный стандарт ISO/IEC 14764 (Standard for Software Engineering - Software Maintenance) определяет сопровождение программного обеспечения в тех же терминах, что и стандарт 12207, придавая @@ -145,9 +145,9 @@ Software Engineering - Software Maintenance) опре коде. Стандарт жизненного цикла 12207 также идентифицирует основные работы по -сопровождению: реализация процесса <сопровождения>, анализ проблем и +сопровождению: реализация процесса сопровождения, анализ проблем и модификаций (изменений), реализаций модификаций, обзор (оценка)/принятие -<решений> по сопровождению, миграция (с одной версии программного продукта на +решений по сопровождению, миграция (с одной версии программного продукта на другую, с одного продукта на другой) и вывод системы из эксплуатации. Эти работы описываются далее в теме 3.2 “Работы по сопровождению” (Maintenance Activities). @@ -229,7 +229,7 @@ R&D – Research and Development). При этом, р - устранение сбоев - улучшение дизайна -- реализация расширений <функциональных возможностей> +- реализация расширений функциональных возможностей - создание интерфейсов взаимодействия с другими (внешними) системами - адаптация (например, портирование) для возможности работы на другой аппаратной платформе (или обновленной платформе), применения новых системных @@ -338,11 +338,11 @@ Engineering - Software Maintenance введением ISO/IEC 14764 (Standard for Software Engineering - Software Maintenance) классифицирует адаптивное и совершенствующее сопровождение как работы по -расширению <функциональности> продукта. Этот стандарт также объединяет +расширению функциональности продукта. Этот стандарт также объединяет корректирующую и профилактическую деятельность в общую категорию работ по корректировке системы. Профилактическое сопровождение (новейшая категория работ по сопровождению) наиболее часто проводится для программных систем, связанных с -вопросами безопасности <людей>. +вопросами безопасности людей. ![Таблица 1. Категории сопровождения программного обеспечения.](images/maintenance_categories.jpg) @@ -432,7 +432,7 @@ ISO/IEC 14764 (Standard for Software Engineering - Sof в том, что часто сложно найти время для необходимого тестирования. Не меньшей проблемой является и координации в проведении тестов различными членами группы сопровождения, занимающимеся решением различных задач. Если же система -выполняет критичные <для бизнеса> функции, временный вывод системы из +выполняет критичные для бизнеса функции, временный вывод системы из эксплуатации (как говорят, перевод системы в offline) для выполнения тестов часто оказывается просто невозможен. @@ -444,7 +444,7 @@ ISO/IEC 14764 (Standard for Software Engineering - Sof необходимое расширение интеграционных возможностей), затрагиваемых модулях, персоналом сопровождения будут проводиться стандартные процедуры. К таким процедурам, наравне с журналированием запросов и проводимых работ, могут и, -скорее, должны относиться: анализ влияния <изменений> (impact analysis – см. +скорее, должны относиться: анализ влияния изменений (impact analysis – см. ниже), оценка рисков, тестирование (различными методами, в различном объеме), выпуск предварительных версий патчей/обновлений в ограниченное использование (если это позволяет спецификация системы), использование “клона” системы @@ -802,10 +802,10 @@ Software Maintenance). Работы по сопровождению в стандарте 14764 разбиты на задачи: - Process Implementation – реализация процесса -- Problem and Modification Analysis – анализ проблем и <необходимых> +- Problem and Modification Analysis – анализ проблем и необходимых модификаций - Modification Implementation –проведение модификаций (реализация изменений) -- Maintenance Review/Acceptance – оценка и принятие <проведенных работ> при +- Maintenance Review/Acceptance – оценка и принятие проведенных работ при сопровождении - Migration – миграция (на модифицированную или новую версию программного обеспечения) @@ -829,7 +829,7 @@ Agile-методологии, активно разв и обновлять документацию по мере разработки и/или выпуска обновленных или новых релизов продукта. Стандарт ISO/IEC 14764 рекомендует, чтобы персонал или организации, отвечающие за сопровождение, в случае использования элементов -процессов разработки в своей деятельности, адаптировали эти процессы <целиком> +процессов разработки в своей деятельности, адаптировали эти процессы целиком в соответствии со своими потребностями. В то же время, деятельность по сопровождению обладает и определёнными уникальными чертами, что приводит к необходимости использования специализированных процессов. @@ -915,9 +915,9 @@ Desk и Software Support – эти функции, о отчетов - Достижения соглашения с пользователями о содержании (функциональности, поведении и т.п.) последующих релизов/версий программного обеспечения -- Идентификации потенциальных конфликтов и возможных альтернатив <реализации -необходимых запросов> -- Оценки рисков для <функционирования> текущего релиза и разработки плана +- Идентификации потенциальных конфликтов и возможных альтернатив реализации +необходимых запросов +- Оценки рисков для функционирования текущего релиза и разработки плана “отката” на немодифицированный (текущий, до внесения изменений, касающихся рассматриваемого запроса) вариант системы, в случае возникновения проблем, связанных с модификацией @@ -1032,7 +1032,7 @@ Engineering - Software Maintenance), рекоменд Реинжиниринг определяется как детальная оценка (examination) и перестройка программного обеспечения для формирования понимания, воссоздания (на уровне -модели и, в ряде случаев, требований) и дальнейшей реализации его <функций> в +модели и, в ряде случаев, требований) и дальнейшей реализации его функций в новой форме (например, с использованием новых технологий и платформ, при сохранении существующей и расширением и облегчением возможностей добавлений новой функциональности). Отмечается, что в индустрии существуют различные blob - 01eba18a1ccbc968cb8b2d354ce23219424b4946 blob + 3d700d32475a8c2fec2c54a984a91faaa60e4a82 --- 6_software_configuration_management.md +++ 6_software_configuration_management.md @@ -60,7 +60,7 @@ SCM-деятельность помогает в до требованиями SQA (например, в IEEE 730-02 “Standard for Software Quality Assurance Plans”). -Работы по конфигурационному управлению <программного обеспечения> включают: +Работы по конфигурационному управлению программного обеспечения включают: управление и планирование SCM-процессов, идентификацию программных конфигураций, контроль конфигураций, учет статусов конфигураций, аудит, а также управление выпуском (release management) и поставкой (delivery). @@ -151,15 +151,15 @@ SWEBOK, связанную с данной облас контекстом, в рамках которого проводится такая деятельность. SCM может играть роль интерфейса к работам, направленным на обеспечение -качества (quality assurance), вытекающим, например, из отслеживания записей <по -изменениям> и несогласующихся элементов (например, выявленным в процессе сборки -очередной версии системы, прим. автора). С точки зрения составителей <данной -области знаний SWEBOK>, некоторые элементы, находящиеся под управлением SCM -<процесса>, могут также служить объектами рассмотрения в рамках организационных +качества (quality assurance), вытекающим, например, из отслеживания записей по +изменениям и несогласующихся элементов (например, выявленным в процессе сборки +очередной версии системы, прим. автора). С точки зрения составителей данной +области знаний SWEBOK, некоторые элементы, находящиеся под управлением SCM +процесса, могут также служить объектами рассмотрения в рамках организационных программ по обеспечению качества. Управление несогласующемися элементами обычно относится к работам по управлению качеством. Однако, SCM может обеспечить существенную помощь в отслеживании (трассировке) и создании отчетности по -элементам программных конфигураций, попадающих в такую <проблемную> категорию. +элементам программных конфигураций, попадающих в такую проблемную категорию. SWEBOK отмечает, что возможно тесное взаимодействие между организационными структурами, отвечающими за разработку и сопровождение (и SCM играет роль @@ -179,7 +179,7 @@ SWEBOK отмечает, что возможно те между заказчиком и поставщиком может содержать положения, затрагивающие процесс конфигурационного управления. Например, может требоваться проведение определенных процедур проверки (аудита) или специфицирован набор элементов -(активов, артефактов), передаваемых под управление <процедур и системы> +(активов, артефактов), передаваемых под управление процедур и системы конфигурационного управления (или в части формализации обработки и контроля реализации запросов на изменения, поступающих от заинтересованных лиц). Когда разрабатываемый программный продукт потенциально затрагивает аспекты публичной @@ -218,7 +218,7 @@ Identification) Кроме этого, необходимо принимать во внимание и такие аспекты конфигурационного управления, как организационные вопросы, обязанности, ресурсы и расписание, выбор инструментов и реализация, контроль поставщиков и субподрядчиков, а -также, контроль интерфейсов <взаимодействия программных модулей>. Результаты +также, контроль интерфейсов взаимодействия программных модулей. Результаты планирования сводятся в план конфигурационного управления (SCM Plan - SCMP), обычно, являющийся объектом оценки и аудита в рамках деятельности по обеспечению качества (SQA – Software Quality Assurance). @@ -263,19 +263,19 @@ SCM-деятельность поддерживает - Отчетности по статусу конфигураций и сбору соответствующих метрических показателей - Аудиту конфигураций -- Управлению и отслеживанию <состояния и полноты> программной документации +- Управлению и отслеживанию состояния и полноты программной документации - Выполнению задач по сборке программных продуктов и их модулей - Управлению, контролю и поставке выпусков (релизов) программных продуктов Инструменты, используемые для обеспечения конфигурационного управления, могут также предоставлять метрики, необходимые для совершенствования процессов. SWEBOK обращает внимание (рекомендуя соответствующий первоисточник) на -следующие ключевые индикаторы: работы и прогресс <по их выполнению> (Work and +следующие ключевые индикаторы: работы и прогресс по их выполнению (Work and Progress) и индикаторы качества – поток изменений (Change Traffic), -стабильность <конфигураций> (Stability), раздробленность (Breakage), +стабильность конфигураций (Stability), раздробленность (Breakage), модульность (Modularity), переработка (Rework), адаптируемость (Adaptibility), среднее время между сбоями (MTBF – Mean Time Between Failures), -зрелость/полнота <информации> (Maturity). Отчетность по этим индикаторам может +зрелость/полнота информации (Maturity). Отчетность по этим индикаторам может быть организована различным образом, например, по элементам конфигураций или по типу запросов на изменения. @@ -290,7 +290,7 @@ Progress) и индикаторы качества – поддерживают процесс сборки и выпуска программного обеспечения и документации на основе программных элементов, содержащихся в библиотеках. Инструменты для управления запросами на изменения программного обеспечения используются для -контролируемых <системой конфигурационного управления> программных элементов. +контролируемых системой конфигурационного управления программных элементов. Другие инструменты могут обеспечивать управление базой данных и необходимыми менеджменту отчетными средствами, а также деятельностью по разработке и обеспечению качества. Как уже упоминалось выше, в рамках SCM-системы может быть @@ -527,7 +527,7 @@ Terminology). Программная конфигур #### Базовая линия, срез (Baseline) -Базовая линия или <фиксированный> срез (baseline) программного обеспечения +Базовая линия или фиксированный срез (baseline) программного обеспечения – набор элементов программной конфигурации, формально определенный и зафиксированный по времени в процессе жизненного цикла программного обеспечения. Этот термин также иногда используется для указания конкретной @@ -584,8 +584,8 @@ Evaluating, and Approving Software Changes”. После включения элемента в конфигурацию в качестве SCI, изменения элементов должны утверждаться формально, как связанные с соответствующими элементами (SCI) и базовыми линиями, следуя плану конфигурационного управления (SCMP). -После утверждения <запроса на изменение и проведения работ по изменению>, -<измененный> элемент включается в конфигурацию, в соответствии с заданной +После утверждения запроса на изменение и проведения работ по изменению, +измененный элемент включается в конфигурацию, в соответствии с заданной процедурой утверждения. ### Программная библиотека (Software Library) @@ -593,7 +593,7 @@ Evaluating, and Approving Software Changes”. Программная библиотека – контролируемая коллекция программных приложений и связанной с ними документации, предназначенная для использования в процессе разработки, эксплуатации и сопровождения программного обеспечения (см. IEEE -610.12-90). В качестве <элемента> программной библиотеки, также, может +610.12-90). В качестве элемента программной библиотеки, также, может рассматриваться инструментарий, используемый в работах по выпуску программного обеспечения и передаче его в эксплуатацию (например, инсталляции). На практике могут использоваться различные типы библиотек, каждая из которых соответствует @@ -621,23 +621,23 @@ SCM, необходимый для данной биб запросы на изменения, включая сообщения об обнаруженных дефектах, и т.п.) в многопользовательской среде. На более высоком уровне контроля, доступ ограничен сильнее и SCM (процесс и/или система) является основным пользователем -<библиотеки> (например, для осуществления автоматической сборки продукта по +библиотеки (например, для осуществления автоматической сборки продукта по расписанию). Все эти библиотеки также являются важным источником информации для -количественной оценки работ, их результата и прогресса <в развитии программных -элементов>. +количественной оценки работ, их результата и прогресса в развитии программных +элементов. ## Контроль программных конфигураций (Software Configuration Control) Контроль программных конфигураций касается вопросов управления изменениями в течение жизненного цикла программного обеспечения. Он включает процесс определения того, какие именно изменения должны быть сделаны, какие полномочия -необходимы для утверждения определенных <типов> изменений, в чем состоит +необходимы для утверждения определенных типов изменений, в чем состоит поддержка реализации этих изменений, а также концепцию формального утверждения отклонений от проектных требований, также как и отказа от внесения изменений. Получаемая в результате этого информация полезна для количественной оценки -потока изменений, нарушения целостности <системы> и аспектов “переработки” в +потока изменений, нарушения целостности системы и аспектов “переработки” в проекте (в большинстве случаев, по времени, стоимости и усилиям - трудозатратам). @@ -678,7 +678,7 @@ analysis) запрашиваемых изменени #### Совет по конфигурационному контролю (Software Configuration Control Board) Полномочия по принятию или отклонению предлагаемых изменений обычно возлагаются -на <организационную> сущность, называемую совет по конфигурационному контролю - +на организационную сущность, называемую совет по конфигурационному контролю - Configuration Control Board (чаще звучит как совет по координации изменений - Change Control Board, CCB). В небольших проектах такие полномочия могут, в действительности, принадлежать лидеру или одному назначенному лицу из числа @@ -702,9 +702,9 @@ Coordination & Control Board – в общем слу #### Процесс обработки запросов на изменения (Software change request process) -Эффективный процесс <обработки> запросов на изменения (SCR process) требует -использования соответствующих средств поддержки и процедур <для данного вида -деятельности>, от “бумажных” форм и документированных процедур (как +Эффективный процесс обработки запросов на изменения (SCR process) требует +использования соответствующих средств поддержки и процедур для данного вида +деятельности, от “бумажных” форм и документированных процедур (как последовательности действий или сценариев) до программных инструментов, позволяющих отсылать запросы на изменения, выполнять процесс обработки таких запросов (изменять их статус, комментировать, детализировать и т.п.), @@ -737,7 +737,7 @@ SWEBOK отмечает, что описания пр расписания. Если набор утвержденных запросов на изменения может выполняться одновременно, необходимо обеспечить отслеживание того, какие именно SCR реализованы в конкретной версии программного продукта и базовой линии -<конфигурации>. Составной частью процесса “закрытия” изменения (по аналогии с +конфигурации. Составной частью процесса “закрытия” изменения (по аналогии с closure - “закрытием”, то есть завершением проекта), является аудит(ы) конфигурации(й) и верификация качества программного обеспечения. Это обеспечивает гарантию того, что были внесены только утвержденные изменения. @@ -746,7 +746,7 @@ closure - “закрытием”, то есть за Фактическая реализация изменений поддерживается инструментальными средствами соответствующей программной библиотеки (см. выше 2.2 “Программная библиотека”), -обеспечивающими управление версиями и поддержку <единого> репозитория кода. Как +обеспечивающими управление версиями и поддержку единого репозитория кода. Как минимум, эти инструменты должны поддерживать операции chek-in/check-out (помещение в репозиторий/ получение из репозитория) и ассоциированные возможности по контролю версий (например, отметка версии – labeling, сравнение @@ -773,7 +773,7 @@ environment). Эти инструменты могут ### Отклонения и отказ от изменений (Deviations and Waivers) Ограничения, накладываемые на усилия, прилагаемые к выполнению определенных -работ <программной инженерии>, как и спецификации, созданные в процессе +работ программной инженерии, как и спецификации, созданные в процессе разработки, могут содержать условия, которые не могут быть удовлетворены в заданной точке жизненного цикла. Отклонение (deviation) - утверждение изменений, внесенных относительно предварительно сформулированных условий к @@ -803,7 +803,7 @@ Accounting, SCSA) подразумевает сохр для получения (и генерации отчетов) информации, необходимой для осуществления процессов жизненного цикла системы. Как и в любой информационной системе, информация о статусе конфигураций должна идентифицироваться, собираться и -поддерживаться <в актуальном состоянии> по мере эволюции этих конфигураций. +поддерживаться в актуальном состоянии по мере эволюции этих конфигураций. Различная информация и количественные показатели необходимы для поддержки процесса конфигурационного управления, а также для генерации отчетности (о статусе конфигураций), необходимой для управления, выполнения процессов @@ -847,15 +847,15 @@ Accounting, SCSA) подразумевает сохр проведения различных количественных оценок в интересах менеджмента, разработки или конфигурационного управления. Например, к такого рода данным относятся: количество запросов на изменения на один конфигурационный элемент; среднее -время, необходимое для реализации запрошенных изменений <заданного типа>. +время, необходимое для реализации запрошенных изменений заданного типа. ## Аудит конфигураций (Software Configuration Auditing) Аудит программного обеспечения – деятельность, выполняемая для независимой -оценки программных продуктов и процессов на <формальное> соответствие +оценки программных продуктов и процессов на формальное соответствие (conformance) применимым в данном случае инструкциям, стандартам, руководящим документам, планам и процедурам (см. IEEE 1028-97 “Standard for Software -Reviews”). Аудиты проводятся в <строгом> соответствии с четко определёнными +Reviews”). Аудиты проводятся в строгом соответствии с четко определёнными процессами, содержащими и определяющими различные роли аудиторов и из обязанности. Каждый аудит должен быть, в свою очередь, четко спланирован и может требовать привлечения многих специалистов для выполнения различных задач @@ -866,7 +866,7 @@ Reviews”). Аудиты проводятся в <с числе, включая стандарт IEEE 1028-97 “Standard for Software Reviews”. Деятельность по аудиту программных конфигураций определяет степень, в которой -элемент <конфигурации> (SCI) удовлетворяет заданным (например, на уровне +элемент конфигурации (SCI) удовлетворяет заданным (например, на уровне требований и/или запросов на изменения) функциональным и физическим характеристикам. Неформальный аудит такого типа может быть связан с ключевыми точками жизненного цикла (вехами проекта, в терминах управления проектами - @@ -909,14 +909,14 @@ Configuration Audit, PCA). Успешное (в тер ## Управление выпуском и поставкой (Software Release Management and Delivery) Термин “релиз” (release, выпуск) используется в данном контексте, подразумевая -распространение <и использование> элементов конфигураций за рамками работ по +распространение и использование элементов конфигураций за рамками работ по разработке программного обеспечения. Это может включать как внутренние релизы, так и выпуск и передачу программного обеспечения заказчикам. В ситуациях, когда доступны для поставки различные версии программных элементов (в частности, различные версии для разных платформ или редакции с различным набором функциональных возможностей), часто бывает необходимо создавать специализированные версии и пакеты (сборки) соответствующих материалов -(элементов, активов) для выпуска в качестве <самостоятельной> версии. +(элементов, активов) для выпуска в качестве самостоятельной версии. Программная библиотека (предоставляющая соответствующий инструментарий для такой сборки) играет ключевую роль в выполнении таких работ. @@ -959,7 +959,7 @@ Configuration Audit, PCA). Успешное (в тер программного обеспечения. Процесс и результаты сборки могут быть необходимы для последующего -использования <в других процессах, работах и проектах> и часто являются +использования в других процессах, работах и проектах и часто являются объектом верификации (проверки) в рамках деятельности по обеспечению качества (SQA). @@ -985,7 +985,7 @@ Configuration Audit, PCA). Успешное (в тер известных проблемах, а также требованиях к платформе(ам), которые необходимо соблюдать для предусмотренного режима эксплуатации продукта. Подготовленный к выпуску пакет (package) также включает инструкции по установке и обновлению -<предыдущей версии>. Создание такой инструкции может быть осложнено тем, что +предыдущей версии. Создание такой инструкции может быть осложнено тем, что некоторые текущие пользователи могут иметь устаревшие версии, более ранние, чем предыдущий выпущенный релиз. Наконец, в ряде случаев, деятельность по управлению выпуском может требовать отслеживание распространения (поставки) @@ -1001,6 +1001,6 @@ Configuration Audit, PCA). Успешное (в тер изменения для отображения содержимого релиза на полученные запросы на изменения (SCR - software change request, включая сообщения об обнаруженных ранее и исправленных в данном релизе ошибках, прим. автора). Эти инструментальные -средства <поддержки управления выпуском продуктов> также могут поддерживать -информацию о различных целевых платформах и <операционном> окружении, +средства поддержки управления выпуском продуктов также могут поддерживать +информацию о различных целевых платформах и операционном окружении, используемом у заказчиков. blob - 000adcbe06357fbc4c9a75e144a68501989a038f blob + 5ad010cbb66b703c77dfc2a9c068d1c4ee908077 --- 7_software_engineering_management.md +++ 7_software_engineering_management.md @@ -228,7 +228,7 @@ activities), предпринимаемые для о - Обзор и оценка (Review and evaluation) – относится к работам по проверке того, что получаемый программный продукт отвечает заданным целям, требованиям, ограничениям и т.п. -- Закрытие <проекта> (Closure) – относится к фиксированию результатов +- Закрытие проекта (Closure) – относится к фиксированию результатов программного проекта после передачи полученного программного продукта в эксплуатацию. - Измерения в программной инженерии (Software engineering measurement) – @@ -355,7 +355,7 @@ Software Quality). Безусловно, что дол ассоциированными входами, выходами и условиями завершения (completion), например, в форме структуры декомпозиции работ – WBS (work breakdown structure). Это влияет на высокоуровневое (первичное) определение проектного -расписания и организационной структуры <проектной команды>. +расписания и организационной структуры проектной команды. ### Определение результатов (Determine Deliverables) @@ -418,7 +418,7 @@ structure). Это влияет на высокоур В совокупности, вся эта деятельность является итеративной и должна обсуждаться и проводиться до тех пор, пока не будет достигнут консенсус между соответствующими заинтересованными лицами – в первую очередь, менеджментом -<проекта> и инженерами <входящими в команду проекта>. +проекта и инженерами входящими в команду проекта. ### Распределение ресурсов (Resource Allocation) @@ -505,7 +505,7 @@ quality assurance) на протяжении всех План проекта реализуется за счет выполнения процессов, представленных в плане. Следование плану на протяжении выполнения проекта связано с ожиданиями, что -соблюдение <корректно составленного> плана приводит к успешному удовлетворению +соблюдение корректно составленного плана приводит к успешному удовлетворению требований заинтересованных лиц и достижению целей проекта. Основой для успешного выполнения проекта является управленческая деятельность по ведению оценки и измерений, мониторинга, контроля и отчетности. @@ -536,8 +536,8 @@ Measurement Process). ### Процесс мониторинга (Monitor Process) Соблюдение плана проверяется постоянно и через предопределенные интервалы -времени. Анализируются выходы (outputs) и условия завершения <задач>. -Получаемые <в процессе измерений> результаты оцениваются в терминах требуемых +времени. Анализируются выходы (outputs) и условия завершения задач. +Получаемые в процессе измерений результаты оцениваются в терминах требуемых характеристик (например, через процедуры обзора/оценки и аудита – review, audit). Затраты усилий (efforts), соблюдения расписания, стоимость к данному моменту, используемые ресурсы – все это исследуется к каждой дате оценки. При @@ -545,7 +545,7 @@ audit). Затраты усилий (efforts), соб проверка удовлетворения требований качества. Моделируются и анализируются данные измерений. Анализ расхождений (variance -analysis) <плана с реальным выполнением проекта> базируется на оценке +analysis) плана с реальным выполнением проекта базируется на оценке отклонений реальных данных от планируемых и ожидаемых. Такой анализ может проводиться в отношении оценки перерасхода средств (cost overrun), нарушения расписания и других важных характеристик – ограничений проекта Часто @@ -607,7 +607,7 @@ analysis) <плана с реальным выполн В критических точках проекта оценивается общий (по всему проекту) прогресс в достижении установленных целей и удовлетворении требований заинтересованных лиц. Аналогично, проводится оценка (assessment) эффективности процессов, -<работы> персонала, а также инструментов и методов, использованных в работах, +работы персонала, а также инструментов и методов, использованных в работах, проведенных за заданный промежуток времени. ### Определение удовлетворения требованиям (Determining Satisfaction of Requirements) @@ -647,10 +647,10 @@ analysis) <плана с реальным выполн анализу результатов, полученных в процессе работы над проектом (post mortem analysis), и улучшению процессов (process improvement). -### Определение <критериев> закрытия проекта (Determining Closure) +### Определение критериев закрытия проекта (Determining Closure) Проект закрывается, когда завершены специфицированные в плане проекта задачи и -подтверждено <удовлетворительное> достижение критериев завершения (completion +подтверждено удовлетворительное достижение критериев завершения (completion criteria) проекта. При этом, все запланированные результаты (продукт, его модули и т.п.) должны быть переданы заказчику и/или в эксплуатацию с приемлемыми (с точки зрения требований) и принятыми (со стороны заказчика) @@ -669,7 +669,7 @@ acceptance list, например, по результ о “подтверждении закрытия/завершения проекта”) создается архив материалов в соответствии с утверждёнными заинтересованными лицами методами, местоположением, формой и заданной длительностью хранения. База данных -измерений <в организации> обновляется в соответствии с полученными финальными +измерений в организации обновляется в соответствии с полученными финальными данными проекта и проводится пост-проектный анализ этих данных. Анализ по завершении проекта помогает в оптимизации процессов, практик и организационной структуры (см. область знаний Software Engineering Process). @@ -750,8 +750,8 @@ Process (2002 г.), основывающемся на характеристик организационной единицы в уже упомянутом стандарте ISO 15939-02 (ISO/IEC 15939:2002 Software Engineering - Software Measurement Process, раздел 5.2.1). -- Идентификация информационных потребностей <в отношении результатов -измерений>. Такие потребности, обычно, базируются на целях, ограничениях, +- Идентификация информационных потребностей в отношении результатов +измерений. Такие потребности, обычно, базируются на целях, ограничениях, рисках и проблемах на уровне заданной организационной единицы. В основе указанных аспектов лежат различные цели – организационные, проектные и т.п. Все эти аспекты (как и порождающие их цели) должны быть четко идентифицированы и @@ -766,14 +766,14 @@ Process (2002 г.), основывающемся на (например, в силу недостатка ресурсов), легкость анализа, легкость получения точных и целостных данных и т.п. (см. стандарт ISO 15939-02, раздел 5.2.3 и приложение C). -- Определение наборов <собираемых> данных, а также процедур анализа и ведения +- Определение наборов собираемых данных, а также процедур анализа и ведения отчетности. Это включает в себя коллекцию процедур и расписаний, хранение, проверку, анализ, отчетность и конфигурационное управление собираемыми данными. (см. стандарт ISO 15939-02, раздел 5.2.4). - Определение критериев оценки информационных продуктов (т.е. результатов измерений). На критерии оценки влияют технические и бизнес цели, сформулированные прежде для соответствующей организационной единицы. Результаты -измерений* ассоциированы с создаваемым продуктом <являющемся целью проекта>, а +измерений* ассоциированы с создаваемым продуктом являющемся целью проекта, а также с процессами, обеспечивающими управление и измерения в проекте. (см. стандарт ISO 15939-02, раздел 5.2.5 и приложения D, E). * в данной теме в отношении результатов измерений часто используется термин @@ -786,7 +786,7 @@ Process (2002 г.), основывающемся на установлены на уровне организационной единицы или выше. Такие критерии должны принимать во внимание существующий опыт, доступность ресурсов и потенциальный срыв проекта когда предлагается изменение существующих практик. Утверждение -(approval) <выделения ресурсов> демонстрирует поддержку и принятие обязательств +(approval) выделения ресурсов демонстрирует поддержку и принятие обязательств по проведению измерений. (см. стандарт ISO 15939-02, раздел 5.2.6.1 и приложение F). - Ресурсы должны быть доступны для реализации запланированных и утвержденных @@ -797,7 +797,7 @@ Process (2002 г.), основывающемся на подразделения или организации). Также, необходимо уделять внимание ресурсам, необходимым для успешного внедрения новых процедур и измерений (метрик). (см. стандарт ISO 15939-02, раздел 5.2.6.2). -- Овладевание и внедрение технологий поддержки <измерений>. Это включает оценку +- Овладевание и внедрение технологий поддержки измерений. Это включает оценку доступных технологий, выбор наиболее соответствующих (заданному контексту и ограничениям) технологий, их приобретение и овладевание ими и, наконец, внедрение в повседневную практику. (см. стандарт ISO 15939-02, раздел 5.2.7). @@ -820,8 +820,8 @@ Process (2002 г.), основывающемся на Анализ данных и процедуры отчетности должны быть интегрированы в организационные и/или проектные процессы. (см. стандарт ISO 15939-02, раздел 5.3.1). -- Сбор данных. Данные должны собираться, верифицироваться и сохраняться <для -дальнейшего использования>. (см. стандарт ISO 15939-02, раздел 5.3.2). +- Сбор данных. Данные должны собираться, верифицироваться и сохраняться для +дальнейшего использования. (см. стандарт ISO 15939-02, раздел 5.3.2). - Анализ данных и создание информационного продукта (как результата измерений, позволяющего принимать на его основе те или иные решения). Данные могут агрегироваться, трансформироваться или записываться как часть процесса анализа @@ -861,7 +861,7 @@ Strengths, Weaknesses, Opportunities, Threats – си полученные результаты. Сделанные выводы должны быть записаны в соответствующую базу данных. (см. стандарт ISO 15939-02, раздел 5.4.1 и приложение D). - Определение потенциальных возможностей улучшения/усовершенствований -(improvements) <процесса проведения измерений>. Такие рекомендации по улучшению +(improvements) процесса проведения измерений. Такие рекомендации по улучшению могут заключаться в изменении формата используемых количественных индикаторов, единиц измерения или изменений в их классификации (категориях метрик). Необходимо определять стоимости и отдачу (benefits) от предлагаемых улучшений и blob - 2220ace2390d547db17e338f5299c1d99254e626 blob + 0848601fd72adb8b854f7a2ea3d6baf8fbed8109 --- 8_software_engineering_process.md +++ 8_software_engineering_process.md @@ -91,11 +91,11 @@ Process”). Для внедрения процессов жизненного цикла необходимо обладать соответствующей инфраструктурой, подразумевая, что ресурсы (компетентный персонал, инструменты, -финансирование) – доступны, а ответственность – распределена <по членам +финансирование) – доступны, а ответственность – распределена по членам проектной команды и/или организационной единицы, в терминах структуры компании -или организации, например, отдела или группы>. Выполнение этих задач является -хорошим индикатором того, что менеджмент <управленческий персонал -проекта/организации> реально прилагает усилия по поддержке процесса программной +или организации, например, отдела или группы. Выполнение этих задач является +хорошим индикатором того, что менеджмент управленческий персонал +проекта/организации реально прилагает усилия по поддержке процесса программной инженерии. Как следствие таких усилий могут создаваться различные комитеты и другие специализированные организационные структуры и органы, в общем случае называемые steering committee – “управляющий комитет”, обладающий @@ -116,8 +116,8 @@ Process”). SEPG создается как центральный орган, принимающий на себя работу по process improvement - совершенствованию процесса(-ов). SEPG берет на себя ответственность по множеству вопросов, связанных с этой задачей в терминах -инициирования <улучшений> и поддержки <существующего процесса и его постоянного -совершенствования>. +инициирования улучшений и поддержки существующего процесса и его постоянного +совершенствования. Часто SEPG формируется из нескольких ведущих членов проектной команды (если, SEPG создается в рамках проекта) или на уровне подразделения или всей @@ -143,8 +143,8 @@ SEPG создается в рамках проекта Основной задачей EF является институализация (внедрение в повседневную практику) коллективного опыта и полученных уроков в масштабах организации на основе разработки, обновления и внедрения в проектную организацию “пакетов -опыта” – experience packages (например, руководств, моделей, курсов обучения и -т.п.), <типовых> “активов процесса” – process assets. Проектная организация +опыта” – experience packages (например, руководств, моделей, курсов обучения и +т.п.), типовых “активов процесса” – process assets. Проектная организация предлагает на рассмотрение EF свои продукты, планы, использовавшиеся при разработке, а также данные, собранные в процессе разработки и эксплуатации. @@ -165,8 +165,8 @@ SEPG проводит пилотное внедрен ### Цикл управления программным процессом (Software Process Management Cycle) Управление процессами в области программного обеспечения состоит из четырех -действий, представленных в рамках итеративного цикла. Это позволяет получать и -анализировать отклики на постоянной основе и, <более оперативно> +действий, представленных в рамках итеративного цикла. Это позволяет получать и +анализировать отклики на постоянной основе и, более оперативно совершенствовать процесс. Вот эти четыре действия, предлагаемые SWEBOK: - Establish Process Infrastructure – создание инфраструктуры процесса. Задачи – @@ -177,8 +177,8 @@ SEPG проводит пилотное внедрен - Planning – планирование. Задача (цель) – понять (сформулировать) текущие бизнес-цели и потребности в процессе, необходимые отдельным специалистам, проекту и/или организации, в целом; идентифицировать сильные и слабые стороны -(см. концепцию SWOT-анализа в различных источниках) <существующего процесса и -планируемых на данной итерации нововведений и/или изменений> и разработать план +(см. концепцию SWOT-анализа в различных источниках) существующего процесса и +планируемых на данной итерации нововведений и/или изменений и разработать план реализации и изменения процесса. - Process Implementation and Change – реализация и изменение процесса. Задача (цель) – выполнение разработанного плана по внедрению нового и/или @@ -329,7 +329,7 @@ for the Application of ISO9001:2000 to Computer Softwa Некоторые процессы жизненного цикла придают особое значение быстрому вводу в эксплуатацию (rapid delivery) программных систем и глубокой вовлеченности -пользователей <в процесс разработки>. Такие процессы называют agile-методами – +пользователей в процесс разработки. Такие процессы называют agile-методами – быстрыми, живыми, подвижными. К ним относится, например, экстремальное программирование – eXtreme Programming (XP, см. работы Кента Бека – Kent Beck). Отличительной особенностью этих методов является гибкость в вопросах @@ -448,7 +448,7 @@ SWEBOK отмечает, что ряд моделей ### Методы оценки процесса (Process Assessment Methods) -Для надлежащего проведения оценки соответствующие методы <оценки> позволяют +Для надлежащего проведения оценки соответствующие методы оценки позволяют получить количественные параметры, характеризующие возможности оцениваемого процесса (или зрелости организации, в целом). @@ -494,7 +494,7 @@ CMMI Appraisal Method for Process Improvement). Дея инженерии, лежащих в основе многих более детальных измерений и процессов анализа. Более того, результаты усилий по совершенствованию процессов и продуктов, могут быть оценены только в том случае, если установлены -количественные характеристики заданных параметров <процессов и продуктов> для +количественные характеристики заданных параметров процессов и продуктов для заданных вех или, более точно (так как измерения, все же, выходят за рамки вех конкретных проектов, если, конечно, сама SPI-деятельность не позиционировать как проект, что, конечно, возможно), так называемых “базовых линий” @@ -545,7 +545,7 @@ Measurement Process” и международном ![Рисунок 2. Связь между процессом и его результатами (или "выходом процесса" - process outcome).](images/process_in-out.jpg) Далеко не каждый процесс обладает положительным влиянием на получаемые -результаты. Например, внедрение инспекции <получаемого> программного +результаты. Например, внедрение инспекции получаемого программного обеспечения может сократить усилия и стоимость по тестированию, но может и увеличить время, если каждая инспекция приводит к нарушению расписания просто в силу продолжительности соответствующих инспекционных действий. Поэтому, @@ -580,7 +580,7 @@ Lines Of Code или FP за человеко-меся сопровождаемости, большей удовлетворенности пользователей) мы должны внедрить соответствующие процессы. -Конечно, не только процессы непосредственно влияют на результат <проекта>. +Конечно, не только процессы непосредственно влияют на результат проекта. Существуют и другие факторы, играющие не менее важную роль, например, возможности инструментов и потенциал, знания и опыт специалистов. Когда оценивается влияние изменения процессов, такие факторы должны учитываться @@ -623,7 +623,7 @@ Practices Manual” Существует широкий спектр метрик, которые можно использовать для оценки структуры программного обеспечения – в отношении высокоуровневого и низкоуровневого дизайна, а также артефактов кода для анализа потоков работ, -потоков данных, вложенности <вызовов>, структур контроля, модульности, +потоков данных, вложенности вызовов, структур контроля, модульности, взаимодействия и т.п. #### Оценка качества (Quality measurement) @@ -681,8 +681,8 @@ metrology). возможно построить соответствующие информационные модели на основе собранных данных и имеющихся знаний. -Эти модели применяются для анализа, классификации и предсказания <характеристик -и поведения измеряемых объектов>. Оценка моделей необходима для обеспечения +Эти модели применяются для анализа, классификации и предсказания характеристик +и поведения измеряемых объектов. Оценка моделей необходима для обеспечения достаточной степени точности и понимания их ограничений. Также необходимо отметить важность работ, направленных на уточнение моделей как в процессе ведения проекта, так и после его завершения. @@ -732,13 +732,13 @@ metrology). например, подходом QIP (Quality Improvement Paradigm) состоит из цикла “понимание-проверка-приложение”. Техники, представленные ниже, приведены в качестве других примеров аналитического подхода к измерениям и отражают -достаточно типичную практику реализации такого <аналитического> взгляда на +достаточно типичную практику реализации такого аналитического взгляда на проведение количественной оценки. Будут или нет использоваться эти техники в практике конкретной организации зависит, как минимум, от зрелости ее организационной культуры и используемых процессов. - Экспериментальные исследования (Experimental Studies). Проводятся в -специально подготовленном “окружении” для оценки <нового или измененного> +специально подготовленном “окружении” для оценки нового или измененного процесса. Обычно новый (или измененный) процесс сравнивается с существующим для определения того, в какой степени “старый” процесс дает лучшие результаты, по сравнению с новым процессом. blob - 91b075ee2ec43b279e84820ece36d7cc249e2efb blob + 8cd06eb3708beed03d1812e2fbd82b9779669929 --- 9_software_engineering_tools_and_methods.md +++ 9_software_engineering_tools_and_methods.md @@ -28,9 +28,9 @@ Methods) деятельности в соответствие с заданным систематическим подходом и более вероятным и скорым, с точки зрения соответствующего метода, достижением успеха. Методы обычно предоставляют соответствующие соглашения (нотацию), словарь -<терминов и понятий> и процедуры выполнения идентифицированных (и охватываемых -методом) задач, а также рекомендации по оценке и проверке <выполняемого> -процесса и <получаемого в его результате> продукта. Методы, как и инструменты, +терминов и понятий и процедуры выполнения идентифицированных (и охватываемых +методом) задач, а также рекомендации по оценке и проверке выполняемого +процесса и получаемого в его результате продукта. Методы, как и инструменты, варьируются по содержанию (охватываемой области применения) от отдельной фазы жизненного цикла (или даже процесса) до всего жизненного цикла. Данная область знаний касается только методов, охватывающих множество фаз (этапов) жизненного @@ -108,7 +108,7 @@ Development, обладающая более ёмки случаев (что подтверждается конкретными программными средствами, доступными на рынке программного обеспечения), в качестве инструмента работы с требованиями может выступать и система конфигурационного управления, если, конечно, она -изначально не ограничена базовой функциональностью контроля версий <файлов>. С +изначально не ограничена базовой функциональностью контроля версий файлов. С другой стороны, сегодняшние средства моделирования на основе UML и BPMN могут также рассматриваться как элементы инструментального обеспечения работы с требованиями, что часто отражается в их функциональности, включающей тесную @@ -122,7 +122,7 @@ Development, обладающая более ёмки Эта тема охватывает инструменты для создания и проверки программного дизайна. Существует большое разнообразие таких инструментов, использующих различные нотации (соглашения, в том числе визуальные) и методы. Несмотря на такое -разнообразие, <авторами SWEBOK> не было найдено <адекватной> классификации этих +разнообразие, авторами SWEBOK не было найдено адекватной классификации этих инструментов. Однако, в данном случае, все же возможно разделение инструментов по нескольким @@ -141,7 +141,7 @@ Development, обладающая более ёмки машинного выполнения. - Редакторы (program editors). Эти инструменты используются для создания и -модификации <исходного кода> программ и, возможно, ассоциированной с ними +модификации исходного кода программ и, возможно, ассоциированной с ними документации. Это могут быть как редакторы “общего назначения” (что на протяжении многих лет наблюдается в UNIX и unix-подобных средах) или специализированные редакторы с поддержкой специфики целевого языка @@ -176,7 +176,7 @@ Development, обладающая более ёмки (трансляции) исходного кода к исполнению. - Отладчики (debuggers). Эти инструменты было принято выделить в самостоятельную категорию, так как они поддерживают процесс конструирования -программного обеспечения, но, в то же время, <функционально> отличаются от +программного обеспечения, но, в то же время, функционально отличаются от редакторов и компиляторов. С точки зрения классификации инструментов необходимо выделить явно и давно @@ -205,7 +205,7 @@ Amazon и др.), которые включают на позволяющем отслеживать поведение объекта, подвергаемого тестированию. - Инструменты оценки тестов (test evaluation tools). Эти инструменты поддерживают оценку результатов выполнения тестов, помогая определить в какой -степени и где именно обнаруженное поведение <тестируемого объекта> +степени и где именно обнаруженное поведение тестируемого объекта соответствует ожидаемому поведению. - Средства управления тестами (test management tools). Эти средства обеспечивают поддержку всех аспектов процесса тестирования программного @@ -214,7 +214,7 @@ Amazon и др.), которые включают на инструменты используются для количественной оценки и анализа производительности программного обеспечения, являющегося специализированным видом тестирования, цель которого – в оценки поведения программ в части производительности, в -отличие от тестирования <корректности> функционального поведения. +отличие от тестирования корректности функционального поведения. Последний класс инструментов тестирования, в какой-то степени, показывает недостаточность предложенной классификации, упуская, например, инструменты @@ -324,7 +324,7 @@ Maintenance”. - Инструменты (статического) анализа. Эти средства используются для анализа программных артефактов, данных, потоков работ и зависимостей. Такие инструменты предназначены для проверки определенных свойств или артефактов, в целом, на -соответствие <заданным характеристикам>. +соответствие заданным характеристикам. ### Дополнительные аспекты инструментального обеспечения (Miscellaneous Tool Issues) @@ -346,7 +346,7 @@ SWEBOK идентифицированы три кат (heuristic methods), касающиеся неформализованных подходов; формальные методы (formal methods), обоснованные математически; методы прототипирования (prototyping methods), базирующиеся на различных формах прототипирования. Эти -три темы не являются изолированными <друг от друга>, скорее они выделены исходя +три темы не являются изолированными друг от друга, скорее они выделены исходя из их значимости и на основе определенных достаточно явных индивидуальных особенностей. Например, объектно-ориентированный подход может включать формальные техники и использовать прототипирование для проверки и аттестации. @@ -372,7 +372,7 @@ SWEBOK идентифицированы три кат - Методы, ориентированные на конкретную область применения (domain-specific methods). Такие специализированные методы разрабатываются с учетом специфики решаемых задач, например, систем реального времени, безопасности -<жизнедеятельности> (safety) и защищенности <от несанкционированного доступа> +жизнедеятельности (safety) и защищенности от несанкционированного доступа (security). ### Формальные методы (Formal Methods) @@ -406,8 +406,8 @@ methods). Такие специализированн качестве результата применения таких методов рассматривается конечный - исполнимый программный продукт. - Подтверждение/доказательство (verification/proving properties). Этот подход -основывается на строгом доказательстве точности <любых> характеристик <исходных -предпосылок и получаемого продукта> с использованием теорем и проверки точности +основывается на строгом доказательстве точности любых характеристик исходных +предпосылок и получаемого продукта с использованием теорем и проверки точности моделей. История программной инженерии показала, что в области разработки прикладных @@ -436,7 +436,7 @@ methods). Такие специализированн (часто основывается как на формальных методах). - Цели прототипирования. Примерами таких целей служат требования, архитектурный дизайн или пользовательский интерфейс. -- Техники оценки/исследования (evaluation) <результатов> прототипирования. Эти +- Техники оценки/исследования (evaluation) результатов прототипирования. Эти аспекты касаются того, как именно будут использованы результаты создания прототипа (например, будет ли он трансформирован в продукт, создается он для оценки нагрузочных способностей и других аспектов масштабируемости и т.п.). blob - 5dbe36c867b957748fef5d4d9e60e8a6ec720c6f blob + 8fa41573f0d66e07e2301ddadc09746a2199364c --- software_lifecycle_models.md +++ software_lifecycle_models.md @@ -56,7 +56,7 @@ Lifecycle Management* - PLM). обеспечения возможности управления) более четкое разграничение фаз проекта (что не подразумевает их линейного и последовательного выполнения). -Ниже приведены определения <модели> жизненного цикла программной системы, +Ниже приведены определения модели жизненного цикла программной системы, даваемые, например, в различных вариантах стандартов ГОСТ: - Модель жизненного цикла - структура, состоящая из процессов, работ и задач, включающих в себя разработку, эксплуатацию и сопровождение программного @@ -142,8 +142,8 @@ Processes” – “Процессы жизненно методологией. В частности, выбор и применение метрик оценки качества программной системы и процессов находятся за рамками стандарта 12207, а концепция совершенствования процессов рассматривается в стандарте ISO/IEC 15504 -“Information Technology - Software Process Assessment” (“Оценка процессов <в -области> программного обеспечения”). +“Information Technology - Software Process Assessment” (“Оценка процессов в +области программного обеспечения”). Необходимо отметить заложенные в стандарте ключевые концепции рассмотрения жизненного цикла программных систем. @@ -652,7 +652,7 @@ Architecting and Software Engineering (MBASE), Боэ В результате, можно определить общий набор контрольных точек в сегодняшней спиральной модели: -- *Concept of Operations (COO)* – концепция <использования> системы; +- *Concept of Operations (COO)* – концепция использования системы; - *Life Cycle Objectives (LCO)* – цели и содержание жизненного цикла; - *Life Cycle Architecture (LCA)* – архитектура жизненного цикла; здесь же возможно говорить о готовности концептуальной архитектуры целевой программной