commit - 8f334207e4e7e15a406d129993b67cf9b714f068
commit + 0f568d073ef5dd305ae624595c9691a0ada6fabd
blob - 96051e5bc4d4a912e60d498a0512e7670aaa351b
blob + d064c732c739615c9a4d403d24a6d010c3c8956c
--- 10_software_quality.md
+++ 10_software_quality.md
## Основы качества программного обеспечения (Software Quality Fundamentals)
-Согласие, достигнутое по требованиями к качеству (в оригинале - quality
+Согласие, достигнутое по требованиям к качеству (в оригинале - quality
requirements), наравне с четким доведением до инженеров того, что составляет
качество <получаемого продукта>, требуют обсуждения и формального определения
многих аспектов качества.
Команда <технической оценки> следует заданной процедуре оценки.
Квалифицированные (с технической точки зрения) лица представляют обзор продукта
(представляя команду разработки). Исследование <продукта> проводится в течение
-одной и более встреч (между теми, кто представляет продукт и теми, кто провидит
+одной и более встреч (между теми, кто представляет продукт и теми, кто провoдит
оценку). Техническая оценка завершается после того, как выполнены все
предписанные действия по исследованию продукта.
применяется к критическим фрагментам программного обеспечения (что, вообще
говоря, мало связано с формальными методами – это естественный путь достижения
приемлемого качества при минимизации затрат). Чаще всего они используются для
-верификации особо важных частей критически-важных систем, например, конкректных
+верификации особо важных частей критически-важных систем, например, конкретных
требований <информационной> безопасности и надежности.
#### Динамические техники (Dynamic techniques)
blob - 5fd15c46c15df89c024f789cc4c29baff0c34108
blob + 50f296d2f36e35e97071af397c4ad79672eae31a
--- 1_software_requirements.md
+++ 1_software_requirements.md
замечаниями и комментариями.
Программные требования – software requirements – свойства программного
-обеспечени, которые должны быть надлежащим образом представлены в нём для
+обеспечения, которые должны быть надлежащим образом представлены в нём для
решения конкретных практических задач. Данная область знаний касается вопросов
извлечения (сбора), анализа, специфицирования и утверждения требований.
практическими потребностями.
На практике часто применяется подход, используемый в различных методологиях
-разработки по и базирующийся на определении групп требований к продукту. Такой
+разработки ПО и базирующийся на определении групп требований к продукту. Такой
подход обычно включает группы (типы, категории) требований, например:
системные, программные, функциональные, нефункциональные (в частности, атрибуты
качества) и т.п. Классический пример (см. рисунок 1) высокоуровневого
обязанностей в рамках бизнес-требований и в контексте пользовательских
требований.
-- Группа нефункциоНальных Требований (non-functional requirements)
+- Группа нефункциональных Требований (non-functional requirements)
- Бизнес-правила (business rules) – включают или связаны с корпоративными
регламентами, политиками, стандартами, законодательными актами,
внутрикорпоративными инициативами (например, стремление достичь зрелости
использующие бизнес-правила.
Рассматривая бизнес-правила, как артефакты относящиеся к области программных
-требований можно отметить, вернее дать одно из пояснений, почему бп относят к
+требований можно отметить, вернее дать одно из пояснений, почему бизнес-правила относят к
нефункциональным требованиям: например, при написании определенного шага в
сценарии use case, используется ссылка на бизнес правило: «… система производит
расчет стоимости в соответствии с бизнес-правилом BP41 …». В свою очередь
требует соответствия руководящим документам и прохождения процедур,
определяемых уполномоченными органами.
-- Инженеры по программному обеспечению, иженеры-программисты (Software
+- Инженеры по программному обеспечению, инженеры-программисты (Software
Enginner): лица, обладающие обоснованным интересом к разработке программного
обеспечения, например, повторному использованию тех или иных компонент,
библиотек, средств и инструментов. Именно инженеры ответственны за техническую
и только потом приступать к ее устранению, в частности через улучшение
процессов. Реальная отечественная практика многих организаций, занимающихся
разработкой ПО, показывает, что очень немногие имеют действительно четкое
-представление о том, каким образом организация работы с требованиям может
+представление о том, каким образом организация работы с требованиями может
повлиять на успех компании в целом. Обычно, отечественные компании, в лучшем
случае просто документируют требования, выпуская документы, например,
Техническое задание по ГОСТ. Но действительно ли в этом документе можно увидеть
дальнейшей работы. Осуществление своей профессиональной деятельности
пользователями далеко не гарантирует, к сожалению, способность ясно, четко и
однозначно сформулировать то, что они делают и что именно им необходимо для
-решения их задач сегодня и завтра. Во многом, поэтому, сбор требований,
+решения их задач сегодня и завтра. Во многом, поэтому, сбор требований,
зачастую, превращается в столь тяжелый и часто порождающий конфликты процесс
действительно извлечения, “вытаскивания” информации, без которой невозможно
переходить к дальнейшим проектным работам. Недопонимание между аналитиком и
пользователем, упущение тех или иных аспектов, на первый взгляд кажущихся
второстепенными, неоднозначность или тем более некорректность интерпретации
информации, полученных от пользователей – все это наиболее типичные причины
-“сверх-затрат” (времени, денег и т.п.), а иногда, и полного провала проектов.
+“сверхзатрат” (времени, денег и т.п.), а иногда, и полного провала проектов.
Существует множество практик и подходов, позволяющих добиться действительно
стройной системы требований, отвечающих реальным потребностям и приоритетам
участников проекта и заинтересованных лиц со стороны заказчика, посвященная
обсуждению тех вопросов, ответы на которые не могут быть определены в
результате обычных интервью и которые требуют вовлечения большего количества
-лиц, чем просто пары “пользователь-аналитик”; я позволили себе сконструировать
+лиц, чем просто пары “пользователь-аналитик”; я позволил себе сконструировать
на русском языке этот термин еще и как “запланированный мозговой штурм”, так
как такого рода встречи действительно обычно планируются с заданной
периодичностью для обеспечения однозначности интерпретации информации, значимой
элементы дизайна системы (скажем, логическую модель базы данных). А вот
сценарии использования Use Case часто включают в спецификацию требований
наравне с трассировкой (traces) к соответствующим моделям в форме диаграмм,
-например, к UML Use Case, UML Activity, BPMN и т.п. . Говоря о написании
+например, к UML Use Case, UML Activity, BPMN и т.п.. Говоря о написании
спецификаций требований, то есть одно серьезное заблуждение, которое делают
обычно неопытные аналитики – это фактическая подмена требований как таковых,
моделями графического пользовательского интерфейса, т.е. когда в
документы-спецификации требований просто включаются «картинки»
-пользовательского интерфейса с небольшими пояснениям. Это отнюдь не означает,
+пользовательского интерфейса с небольшими пояснениями. Это отнюдь не означает,
что с заинтересованными лицами и в частности с пользователями, не следует
вообще обсуждать дизайн GUI, часто это имеет смысл делать, но для этого
существует, например, прототипирование. Мне довелось изучить многие документы
ошибками в прототипе и т.п.
- Превращение прототипа в реальную систему за счет постоянного добавления новых
свойств и функциональности “для проверки” – часто бывает нарушена архитектурная
-целостность, необеспечена необходимая масштабируемость и качество получаемого
+целостность, не обеспечена необходимая масштабируемость и качество получаемого
программного продукта;
-Здесь хотелость бы добавить и еще одну типичную проблему - переключение
+Здесь хотелось бы добавить и еще одну типичную проблему - переключение
внимания заинтересованных лиц на эргономику и детали дизайна графического
пользовательского интерфейса, при начальной цели построения прототипа для
выявления функциональных и иных требований и наоборот. Проблема не во внимании
Требования должны быть верифицируемы. Требования, которые не могут быть
проверены и аттестованы (утверждены) – это всего лишь “пожелания”. Именно так
-они буду восприниматься разработчиками, даже в случае их высокой значимости для
+они будут восприниматься разработчиками, даже в случае их высокой значимости для
пользователей. Если описанное требование не сопровождается процедурами проверки
– в большинстве случаев говорят о недостаточной детализации или неполном
описании требования и, соответственно, спецификация требований должна быть
blob - a3c1209a8597fcd736662c66a220f06ce4c58c6a
blob + 56b654df2bded15cdd92b073a88083a3b6953188
--- 4_software_testing.md
+++ 4_software_testing.md
непредусмотренным эффектам”. На практике это означает, что если система успешно
проходила тесты до внесения модификаций, она должна их проходит и после
внесения таковых. Основная проблема регрессионного тестирования заключается в
-поиске компромисса между имеющимеся ресурсами и необходимостью проведения таких
+поиске компромисса между имеющимися ресурсами и необходимостью проведения таких
тестов по мере внесения каждого изменения. В определенной степени, задача
состоит в том, чтобы определить критерии “масштабов” изменений, с достижением
которых необходимо проводить регрессионные тесты.
## Процесс тестирования (Test Process)
-Концепции, стратегии, техники и измерения тестирования должны быть объеденены в
+Концепции, стратегии, техники и измерения тестирования должны быть объединены в
единый процесс тестирования как деятельности по обеспечению качества. Процесс
тестирования поддерживает работы по тестированию и определяет “правила игры”
для членов команды тестирования – от планирования тестов до оценки их
требуют внимания, как минимум, с точки зрения идентификации причин таких помех.
Перед устранением обнаруженного сбоя, необходимо определить и зафиксировать те
усилия, которые необходимы для анализа проблемы, отладки и устранения. Это
-позволит в дельнейшем обеспечить большую глубину измерений, а, соответственно,
+позволит в дальнейшем обеспечить большую глубину измерений, а, соответственно,
в перспективе, иметь возможность улучшения самого процесса тестирования. В тех
случаях, когда результаты тестирования особенно важны, например, в силу
критичности обнаруженного сбоя, может быть сформирована специальная группа
blob - 0c95dd4a427fbff9ddd17b879678be0e54ff91f2
blob + 1b4ef61388db73757127a0b968341e287504c2e3
--- 5_software_maintenance.md
+++ 5_software_maintenance.md
наиболее радикальной и затратной формой изменений программных систем, другие,
что такой подход может применяться и для не столь кардинальных изменений
(например, как смена платформы или архитектуры). Реинжиниринг, обычно,
-провидится не столько для улучшения возможностей сопровождения
+проводится не столько для улучшения возможностей сопровождения
(maintainability), сколько для замены устаревшего программного обеспечения. В
принципе, реинжиниринг можно рассматривать как самостоятельный проект,
включающий в себя, как отмечает SWEBOK, формирование концепции, применение
blob - e311e627c1976f443babe458b440e4f91c5d2a8e
blob + 91b075ee2ec43b279e84820ece36d7cc249e2efb
--- 9_software_engineering_tools_and_methods.md
+++ 9_software_engineering_tools_and_methods.md
кратким делением на категории инструментов и их более детальным определением.
Скорее всего, такая несогласованность связана, в первую очередь, с отсутствием
достигнутого консенсуса в этой области. Базируясь на обеих классификациях,
-упомянутых в SWEBOK, хотелость бы отметить несколько типов инструментов из
+упомянутых в SWEBOK, хотелось бы отметить несколько типов инструментов из
“смежных” областей, имеющих особое значение в поддержке процессов программной
инженерии:
blob - bba382687a04421fd3bed7043660c325497e2cfe
blob + ad17fa54dbf8167615d92fdb1f7403fe0d2f4f78
--- bibliography.md
+++ bibliography.md
Оригинальное издание на английском языке: 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, Государственный Стандарт
