commit 0f568d073ef5dd305ae624595c9691a0ada6fabd from: Sergey Bronnikov date: Tue Jun 04 08:41:59 2024 UTC Fix typos commit - 8f334207e4e7e15a406d129993b67cf9b714f068 commit + 0f568d073ef5dd305ae624595c9691a0ada6fabd blob - 96051e5bc4d4a912e60d498a0512e7670aaa351b blob + d064c732c739615c9a4d403d24a6d010c3c8956c --- 10_software_quality.md +++ 10_software_quality.md @@ -69,7 +69,7 @@ quality” – “стоимость качества ## Основы качества программного обеспечения (Software Quality Fundamentals) -Согласие, достигнутое по требованиями к качеству (в оригинале - quality +Согласие, достигнутое по требованиям к качеству (в оригинале - quality requirements), наравне с четким доведением до инженеров того, что составляет качество <получаемого продукта>, требуют обсуждения и формального определения многих аспектов качества. @@ -531,7 +531,7 @@ IEEE 1028-97 “IEEE Standard for Software Reviews”. Команда <технической оценки> следует заданной процедуре оценки. Квалифицированные (с технической точки зрения) лица представляют обзор продукта (представляя команду разработки). Исследование <продукта> проводится в течение -одной и более встреч (между теми, кто представляет продукт и теми, кто провидит +одной и более встреч (между теми, кто представляет продукт и теми, кто провoдит оценку). Техническая оценка завершается после того, как выполнены все предписанные действия по исследованию продукта. @@ -888,7 +888,7 @@ analysis) и алгоритмический анали применяется к критическим фрагментам программного обеспечения (что, вообще говоря, мало связано с формальными методами – это естественный путь достижения приемлемого качества при минимизации затрат). Чаще всего они используются для -верификации особо важных частей критически-важных систем, например, конкректных +верификации особо важных частей критически-важных систем, например, конкретных требований <информационной> безопасности и надежности. #### Динамические техники (Dynamic techniques) blob - 5fd15c46c15df89c024f789cc4c29baff0c34108 blob + 50f296d2f36e35e97071af397c4ad79672eae31a --- 1_software_requirements.md +++ 1_software_requirements.md @@ -7,7 +7,7 @@ SWEBOK. замечаниями и комментариями. Программные требования – software requirements – свойства программного -обеспечени, которые должны быть надлежащим образом представлены в нём для +обеспечения, которые должны быть надлежащим образом представлены в нём для решения конкретных практических задач. Данная область знаний касается вопросов извлечения (сбора), анализа, специфицирования и утверждения требований. @@ -21,7 +21,7 @@ SWEBOK. практическими потребностями. На практике часто применяется подход, используемый в различных методологиях -разработки по и базирующийся на определении групп требований к продукту. Такой +разработки ПО и базирующийся на определении групп требований к продукту. Такой подход обычно включает группы (типы, категории) требований, например: системные, программные, функциональные, нефункциональные (в частности, атрибуты качества) и т.п. Классический пример (см. рисунок 1) высокоуровневого @@ -120,7 +120,7 @@ Glossary Of Software Engineering Terminology, 1990): обязанностей в рамках бизнес-требований и в контексте пользовательских требований. -- Группа нефункциоНальных Требований (non-functional requirements) +- Группа нефункциональных Требований (non-functional requirements) - Бизнес-правила (business rules) – включают или связаны с корпоративными регламентами, политиками, стандартами, законодательными актами, внутрикорпоративными инициативами (например, стремление достичь зрелости @@ -199,7 +199,7 @@ Constraint Language, BRML – Business Rules Markup La использующие бизнес-правила. Рассматривая бизнес-правила, как артефакты относящиеся к области программных -требований можно отметить, вернее дать одно из пояснений, почему бп относят к +требований можно отметить, вернее дать одно из пояснений, почему бизнес-правила относят к нефункциональным требованиям: например, при написании определенного шага в сценарии use case, используется ссылка на бизнес правило: «… система производит расчет стоимости в соответствии с бизнес-правилом BP41 …». В свою очередь @@ -426,7 +426,7 @@ kshell (популярной командной обо требует соответствия руководящим документам и прохождения процедур, определяемых уполномоченными органами. -- Инженеры по программному обеспечению, иженеры-программисты (Software +- Инженеры по программному обеспечению, инженеры-программисты (Software Enginner): лица, обладающие обоснованным интересом к разработке программного обеспечения, например, повторному использованию тех или иных компонент, библиотек, средств и инструментов. Именно инженеры ответственны за техническую @@ -474,7 +474,7 @@ SWEBOK особо подчеркивает, что е и только потом приступать к ее устранению, в частности через улучшение процессов. Реальная отечественная практика многих организаций, занимающихся разработкой ПО, показывает, что очень немногие имеют действительно четкое -представление о том, каким образом организация работы с требованиям может +представление о том, каким образом организация работы с требованиями может повлиять на успех компании в целом. Обычно, отечественные компании, в лучшем случае просто документируют требования, выпуская документы, например, Техническое задание по ГОСТ. Но действительно ли в этом документе можно увидеть @@ -540,14 +540,14 @@ Engineering Process). В этом контексте, дальнейшей работы. Осуществление своей профессиональной деятельности пользователями далеко не гарантирует, к сожалению, способность ясно, четко и однозначно сформулировать то, что они делают и что именно им необходимо для -решения их задач сегодня и завтра. Во многом, поэтому, сбор требований, +решения их задач сегодня и завтра. Во многом, поэтому, сбор требований, зачастую, превращается в столь тяжелый и часто порождающий конфликты процесс действительно извлечения, “вытаскивания” информации, без которой невозможно переходить к дальнейшим проектным работам. Недопонимание между аналитиком и пользователем, упущение тех или иных аспектов, на первый взгляд кажущихся второстепенными, неоднозначность или тем более некорректность интерпретации информации, полученных от пользователей – все это наиболее типичные причины -“сверх-затрат” (времени, денег и т.п.), а иногда, и полного провала проектов. +“сверхзатрат” (времени, денег и т.п.), а иногда, и полного провала проектов. Существует множество практик и подходов, позволяющих добиться действительно стройной системы требований, отвечающих реальным потребностям и приоритетам @@ -577,7 +577,7 @@ Engineering Process). В этом контексте, участников проекта и заинтересованных лиц со стороны заказчика, посвященная обсуждению тех вопросов, ответы на которые не могут быть определены в результате обычных интервью и которые требуют вовлечения большего количества -лиц, чем просто пары “пользователь-аналитик”; я позволили себе сконструировать +лиц, чем просто пары “пользователь-аналитик”; я позволил себе сконструировать на русском языке этот термин еще и как “запланированный мозговой штурм”, так как такого рода встречи действительно обычно планируются с заданной периодичностью для обеспечения однозначности интерпретации информации, значимой @@ -853,12 +853,12 @@ Requirements Specifications”. элементы дизайна системы (скажем, логическую модель базы данных). А вот сценарии использования Use Case часто включают в спецификацию требований наравне с трассировкой (traces) к соответствующим моделям в форме диаграмм, -например, к UML Use Case, UML Activity, BPMN и т.п. . Говоря о написании +например, к UML Use Case, UML Activity, BPMN и т.п.. Говоря о написании спецификаций требований, то есть одно серьезное заблуждение, которое делают обычно неопытные аналитики – это фактическая подмена требований как таковых, моделями графического пользовательского интерфейса, т.е. когда в документы-спецификации требований просто включаются «картинки» -пользовательского интерфейса с небольшими пояснениям. Это отнюдь не означает, +пользовательского интерфейса с небольшими пояснениями. Это отнюдь не означает, что с заинтересованными лицами и в частности с пользователями, не следует вообще обсуждать дизайн GUI, часто это имеет смысл делать, но для этого существует, например, прототипирование. Мне довелось изучить многие документы @@ -969,10 +969,10 @@ and Audit). ошибками в прототипе и т.п. - Превращение прототипа в реальную систему за счет постоянного добавления новых свойств и функциональности “для проверки” – часто бывает нарушена архитектурная -целостность, необеспечена необходимая масштабируемость и качество получаемого +целостность, не обеспечена необходимая масштабируемость и качество получаемого программного продукта; -Здесь хотелость бы добавить и еще одну типичную проблему - переключение +Здесь хотелось бы добавить и еще одну типичную проблему - переключение внимания заинтересованных лиц на эргономику и детали дизайна графического пользовательского интерфейса, при начальной цели построения прототипа для выявления функциональных и иных требований и наоборот. Проблема не во внимании @@ -1008,7 +1008,7 @@ and Audit). Требования должны быть верифицируемы. Требования, которые не могут быть проверены и аттестованы (утверждены) – это всего лишь “пожелания”. Именно так -они буду восприниматься разработчиками, даже в случае их высокой значимости для +они будут восприниматься разработчиками, даже в случае их высокой значимости для пользователей. Если описанное требование не сопровождается процедурами проверки – в большинстве случаев говорят о недостаточной детализации или неполном описании требования и, соответственно, спецификация требований должна быть blob - a3c1209a8597fcd736662c66a220f06ce4c58c6a blob + 56b654df2bded15cdd92b073a88083a3b6953188 --- 4_software_testing.md +++ 4_software_testing.md @@ -301,7 +301,7 @@ Software Engineering Terminology”) гласит: “ непредусмотренным эффектам”. На практике это означает, что если система успешно проходила тесты до внесения модификаций, она должна их проходит и после внесения таковых. Основная проблема регрессионного тестирования заключается в -поиске компромисса между имеющимеся ресурсами и необходимостью проведения таких +поиске компромисса между имеющимися ресурсами и необходимостью проведения таких тестов по мере внесения каждого изменения. В определенной степени, задача состоит в том, чтобы определить критерии “масштабов” изменений, с достижением которых необходимо проводить регрессионные тесты. @@ -645,7 +645,7 @@ Reliability Engineered Testing) проектируют ## Процесс тестирования (Test Process) -Концепции, стратегии, техники и измерения тестирования должны быть объеденены в +Концепции, стратегии, техники и измерения тестирования должны быть объединены в единый процесс тестирования как деятельности по обеспечению качества. Процесс тестирования поддерживает работы по тестированию и определяет “правила игры” для членов команды тестирования – от планирования тестов до оценки их @@ -839,7 +839,7 @@ IEEE, ISO/IEC, ГОСТ Р 12207 не выделяет требуют внимания, как минимум, с точки зрения идентификации причин таких помех. Перед устранением обнаруженного сбоя, необходимо определить и зафиксировать те усилия, которые необходимы для анализа проблемы, отладки и устранения. Это -позволит в дельнейшем обеспечить большую глубину измерений, а, соответственно, +позволит в дальнейшем обеспечить большую глубину измерений, а, соответственно, в перспективе, иметь возможность улучшения самого процесса тестирования. В тех случаях, когда результаты тестирования особенно важны, например, в силу критичности обнаруженного сбоя, может быть сформирована специальная группа blob - 0c95dd4a427fbff9ddd17b879678be0e54ff91f2 blob + 1b4ef61388db73757127a0b968341e287504c2e3 --- 5_software_maintenance.md +++ 5_software_maintenance.md @@ -1040,7 +1040,7 @@ Engineering - Software Maintenance), рекоменд наиболее радикальной и затратной формой изменений программных систем, другие, что такой подход может применяться и для не столь кардинальных изменений (например, как смена платформы или архитектуры). Реинжиниринг, обычно, -провидится не столько для улучшения возможностей сопровождения +проводится не столько для улучшения возможностей сопровождения (maintainability), сколько для замены устаревшего программного обеспечения. В принципе, реинжиниринг можно рассматривать как самостоятельный проект, включающий в себя, как отмечает SWEBOK, формирование концепции, применение blob - e311e627c1976f443babe458b440e4f91c5d2a8e blob + 91b075ee2ec43b279e84820ece36d7cc249e2efb --- 9_software_engineering_tools_and_methods.md +++ 9_software_engineering_tools_and_methods.md @@ -291,7 +291,7 @@ Maintenance”. кратким делением на категории инструментов и их более детальным определением. Скорее всего, такая несогласованность связана, в первую очередь, с отсутствием достигнутого консенсуса в этой области. Базируясь на обеих классификациях, -упомянутых в SWEBOK, хотелость бы отметить несколько типов инструментов из +упомянутых в SWEBOK, хотелось бы отметить несколько типов инструментов из “смежных” областей, имеющих особое значение в поддержке процессов программной инженерии: blob - bba382687a04421fd3bed7043660c325497e2cfe blob + ad17fa54dbf8167615d92fdb1f7403fe0d2f4f78 --- bibliography.md +++ bibliography.md @@ -79,7 +79,7 @@ Wiley & Sons, Inc. (ISBN 0-471-26557-8) 1976 – Russe Оригинальное издание на английском языке: Software Requirements. Second Edition. Karl E. Wiegers, Microsoft Press (ISBN 0-7356-1879-8), 2003. - [Грей и Ларсон, 2003] – Клиффорд Ф. Грей, Эрик У. Ларсон. Управление -проектами: Практическое русководство. Издательство “Дело и Сервис” (ISBN +проектами: Практическое руководство. Издательство “Дело и Сервис” (ISBN 5-8018-0152-9), 2003. The McGraw-Hill Companies, Inc. (ISBN 0-07-365812-X), 2000. - [ГОСТ 12207, 1999] – Информационная технология. Процессы Жизненного Цикла Программных Средств. ГОСТ Р ИСО/МЭК 12207-99, Государственный Стандарт