commit - 48c63dee92b321ed49c64cb7a2b481a47e98d6af
commit + 8f334207e4e7e15a406d129993b67cf9b714f068
blob - c3f385153806b2b312ff8d616ab8ba9089e5de3f
blob + c939f8b657bead938bc491a82f4f4d6fdefb72e2
--- 0_introduction.md
+++ 0_introduction.md
Version* - Руководство к Своду Знаний по Программной Инженерии, в дальнейшем
просто “SWEBOK” [SWEBOK, 2004];
- *Software Engineering 2004. Curriculum Guidelines for Undergraduate Degree
-Programs in Software Engineering* – Учебный План для Преподавания Программной
+Programs in Software Engineering* – Учебный План для Преподавания Программной
Инженерии в ВУЗах (данное название на русском языке представлено в
вольном смысловом переводе) [SE, 2004].
-
+
## Перевод SWEBOK на русский язык
blob - d02266df811e2001676eccdd567227e02abcad4c
blob + 96051e5bc4d4a912e60d498a0512e7670aaa351b
--- 10_software_quality.md
+++ 10_software_quality.md
противопоставляется “качеству, диктуемому заказчиком”. Конечно, не стоит и
проводить параллель “приемлемого качества” с “продуктом второй свежести”.
Введение категории “приемлемости” в отношении качества является лишь
-прагматичным взглядом на желаемую степень совершенства создаваемого продукта
+прагматичным взглядом на желаемую степень совершенства создаваемого продукта
(услуги), способную удовлетворить пользователей и достижимую в рамках заданных
проектных ограничений. Интересно, что и сама “степень приемлемости” также
выступает в роли ограничения проекта, а в приложении к индустрии программного
от управления требованиями (“атрибуты качества” как категория нефункциональных
требований), до тестирования (т.н. наработка на отказ, такие метрики как MTTF -
Mean Time To Failure, то есть среднее время между обнаруженными сбоями системы,
-и т.п. ). В какой-то степени, “приемлемое качество” можно сравнивать с уровнем
+и т.п.). В какой-то степени, “приемлемое качество” можно сравнивать с уровнем
обслуживания в рамках заданного SLA – Service Level Agreement, давно уже
принятого на вооружение в телекоммуникационной индустрии. Таким образом,
приемлемое качество может рассматриваться как <количественно выраженный>
планирования, (адаптации) и оценки качества программных продуктов. ISO/IEC
определяет три связанных модели качества программного обеспечения (ISO 9126-01
Software Engineering - Product Quality, Part 1: Quality Model) – внутреннее
-качество, внешнее качество и качество в процессе эксплуатации, а также набор
+качество, внешнее качество и качество в процессе эксплуатации, а также набор
соответствующих работ по оценке качества программного обеспечения (ISO14598-98
Software Product Evaluation).
Software Process Assessment”, известный как SPICE - Software Process
Improvement and Capability dEtermination, который также рассматривается в
упомянутой области знаний). Непосредственно с управлением качеством связаны
-процессные области (области компетенции) CMMI: обеспечение качества процесса и
+процессные области (области компетенции) CMMI: обеспечение качества процесса и
продукта (process and product quality assurance, категория процессов CMMI
“Support”), проверка (verification, категория “Engineering”) и аттестация
(validation, категория “Engineering”). При этом, CMMI классифицирует обзор
Качество программного обеспечения может повышаться за счет итеративного
процесса постоянного улучшения. Это требует контроля, координации и обратной
связи в процессе управления многими одновременно выполняемыми процессами: (1)
-процессами жизненного цикла, (2) процессом обнаружения, устранения и
+процессами жизненного цикла, (2) процессом обнаружения, устранения и
предотвращения сбоев/дефектов и (3) процессов улучшения качества.
К программной инженерии применимы теории и концепции, лежащие в основе
Управление качеством программного обеспечения (SQM, Software Quality
Management) применяется ко всем аспектам процессов, продуктов и ресурсов. SQM
-определяет процессы, владельцев процессов, а также требования к процессам,
+определяет процессы, владельцев процессов, а также требования к процессам,
измерения процессов и их результатов, плюс – каналы обратной связи.
Процессы управления качеством содержат много действий. Некоторые из них
Гарантоспособность (dependability) программного обеспечения включает такие
характеристики, как защищенность от сбоев (fault-tolerance), безопасность
использования (safety – безопасность в контексте приемлемого риска для здоровья
-людей, бизнеса, имущества и т.п. ), информационная безопасность или
+людей, бизнеса, имущества и т.п.), информационная безопасность или
защищенность (security – защита информации от несанкционированных операций,
включая доступ на чтение, а также гарантия доступности информации
авторизованным пользователям, в объеме заданных для них прав), а также удобство
Quality Model”).
В обсуждении данного вопроса существенную роль играет обширная литература по
-системам повышенной надежности. При этом, применяется терминология, пришедшая
+системам повышенной надежности. При этом, применяется терминология, пришедшая
из области традиционных механических и электрических систем (в т.ч. не
включающих программное обеспечение) и описывающая концепции опасности, рисков,
целостности систем и т.п. SWEBOK приводит ряд источников, где подробно
SQM-процессы обеспечивают нахождение дефектов. Описание характеристик дефектов
играет основную роль в понимании продукта, облегчает корректировку процесса или
-продукта, а также информирует менеджеров проектов и заказчиков о статусе
+продукта, а также информирует менеджеров проектов и заказчиков о статусе
(состоянии) процесса или продукта. Существуют множество таксономий
(классификации и методов структурирования) дефектов (сбоев). На сегодняшний
день нет четкого консенсуса по этому вопросу и SWEBOK приводит некоторые
требует огромных усилий по интерпретации (и корректировке) ранее определенных
классов дефектов (сбоев). При отслеживании дефектов инженер интересуется не
только их количеством, но и типом. Данный аспект (а именно, распределение
-дефектов по типам) особенно важен для определения наиболее слабых элементов
+дефектов по типам) особенно важен для определения наиболее слабых элементов
системы, с точки зрения используемых технологий и архитектурных решений, что
приводит к необходимости их углубленного изучения, создания специализированных
пилотных проектов, дополнительной проверки концепции (proof of concept, POC –
В процессе разработки и сопровождения программного обеспечения приходится
обращаться к различным видам динамических техник. В основном, это техники
тестирования. Однако, в качестве динамических техник могут рассматриваться
-техники симуляции, проверки моделей и “символического” исполнения (symbolic
+техники симуляции, проверки моделей и “символического” исполнения (symbolic
execution, часто предполагает использование модулей-“пустышек” с точки зрения
выполняемой логики, с эмулируемым входом и выходом при рассмотрении общего
сценария поведения многомодульных систем; иногда под этим термином понимаются и
blob - a15a319d076751d052bb1fed09b0e1f4218801a3
blob + 5fd15c46c15df89c024f789cc4c29baff0c34108
--- 1_software_requirements.md
+++ 1_software_requirements.md
достижения целей.
- Условие или возможность, которые должны удовлетворяться системой/компонентом
системы или которыми система/компонент системы должна обладать для обеспечения
-условий контракта, стандартов, спецификаций или др. регулирующими документами.
+условий контракта, стандартов, спецификаций или др. регулирующими документами.
- Документальная репрезентация (зафиксированное представление, определение,
описание) условий или возможностей, перечисленных в предыдущих пунктах.
В настоящее время разработаны методы и подходы формального представления
бизнес-правил, вплоть до формальных языков описания (использование OCL – Object
-Constraint Language, BRML – Business Rules Markup Language).
+Constraint Language, BRML – Business Rules Markup Language).
Бизнес-правила могут быть не только использованы при определении требований к
разрабатываемому ПО, но и могут отдельно оформляться в дизайне ПО (класс или
Вигерс, описывает feature как “множество логически связанных функциональных
требований, которые предоставляют определенные возможности для пользователя и
удовлетворяют бизнес-целям <организации>”. С точки зрения маркетинга
-программного обеспечения, как отмечает Вигерс, feature это «группа требований,
+программного обеспечения, как отмечает Вигерс, feature это «группа требований,
узнаваемая заинтересованными лицами, которые вовлечены в процесс принятия
решения по приобретению ПО – это список <отличительных особенностей или
возможностей, характеристик>, присутствующий в описании продукта». В то же
Requirements: A Use Case Approach, Second Edition, 2003) определяют feature как
“сервисы, которые оказывает система для удовлетворения одной или более
потребностей заинтересованных лиц (stakeholders needs)”. Ими же отмечается, что
-в реальных проектах могут быть не определены stakeholders needs (а их часто
+в реальных проектах могут быть не определены stakeholders needs (а их часто
выделяют, особенно если у проекта/продукта есть много заинтересованных лиц со
своими потребностями, и эти потребности могут носить взаимоисключающий
характер), но существовать features могут и самостоятельно (как и stakeholder
needs), и конечно же возможно существование и stakeholder needs и features со
взаимной трассировкой.
-Развивая тему features -- Kurt Bittner & Ian Spence в своей книге “Use Case
+Развивая тему features -- Kurt Bittner & Ian Spence в своей книге “Use Case
Modeling” (Kurt Bittner, Ian Spence. Use Case Modeling, 2002), дают схожее,
хотя и более формальное определение features. Они отмечают, что features могут
быть как относящимся к функциональным, так и к нефункциональным требованиям. И
прототипу пользовательского интерфейса на этапе опытной эксплуатации.
Такие требования должны однозначно отвечать на вопросы, предполагающие ответы с
-численными величинами – как часто? насколько быстро? в каком количестве? и т.п.
+численными величинами – Как часто? Насколько быстро? В каком количестве? и т.п.
Большинство требований с количественной оценкой относится к атрибутам качества.
-В качестве примера можно привести реальное требование, присутствующее в
+В качестве примера можно привести реальное требование, присутствующее в
реальном проекте по электронному документообороту: “Система должна производить
поиск документов <определенного вида> за время, не превышающее 5 секунд”. Это
типичное требование с количественной оценкой, в котором определена верхняя
Техническое задание по ГОСТ. Но действительно ли в этом документе можно увидеть
требования – увы. Следуя только рекомендациям, которые есть в ГОСТ можно только
соответствующим образом оформить разделы, что практически никак не влияет на
-качество и информативность документа. Вопросы совершенствования процессов –
+качество и информативность документа. Вопросы совершенствования процессов –
process improvement будут рассматриваться как в главах, посвященных CMMI, так и
в других частях этой книги.
процессы сбора требований, а сами требования – “выходом” этих процессов;
- Сценарии – контекст для сбора пользовательских требований, определяющий
ответы на вопросы “что если” и “как это делается” в отношении бизнес-процессов,
-реализуемых пользователями;
+реализуемых пользователями;
- Прототипы – отличный инструмент для уточнения и/или детализации требований;
существуют разные подходы к прототипированию – от “бумажных” моделей до
пилотных подсистем, реализуемых как самостоятельные (в терминах управления
аналитиков и инженеров рядом с пользователем в процессе выполнения последним
его работ по обеспечению функционирования бизнес-процессов: в определенной
степени можно провести аналогию с практикой присутствия представителя заказчика
-в проектной группе исполнителя ( типовая практика в eXtreme Programming
+в проектной группе исполнителя (типовая практика в eXtreme Programming
“on-site customer” – “присутствующий заказчик”); данная техника является
достаточно затратной, но, в то же время, очень эффективной, а иногда – просто
незаменимой, особенно, если речь идет о достаточно сложных и взаимосвязанных
красивыми квадратиками со стрелочками”. Ни то, ни другое утверждение неверны.
Например, в XP и в других гибких (Agile) практиках существуют и истории
пользователей, и карточки задач, и процедуры анализа (в частности, связанных с
-ними “мозговых штурмов”, как запланированных, так и, к сожалению, не очень) , в
+ними “мозговых штурмов”, как запланированных, так и, к сожалению, не очень), в
результате которого мы сформулировали задачи, высокоуровневые возможности -
“фичи” продукта (feature - особенность), а также необходимые модели (см.
[Амблер, 2002]). Объем моделей, их детализация и средства представления могут
группах – статические модели и поведенческие), связанных и объединенных общей
архитектурой, на основе концепции метамоделей.
-Cовременное состояние стандарта UML (унифицированного языка моделирования
-Unified Modeling Language, разрабатываемого консорциумом OMG – www.omg.org )
+Современное состояние стандарта UML (унифицированного языка моделирования
+Unified Modeling Language, разрабатываемого консорциумом OMG – www.omg.org)
версии 2.0 вполне позволяет говорить о расширении его применимости в “чистом”
бизнес-моделировании. На фоне богатства выразительных средств, появления
соответствующего инструментального обеспечения работы с UML 2.0, длительной
требований” (user requirements specification) или “концепция” (concept <of
operations>), описывает системные требования. Содержание документа определяет
высокоуровневые требования, часто – стратегические цели, для достижения которых
-создается программная система. Принципиальным моментом является то, что такой
+создается программная система. Принципиальным моментом является то, что такой
документ описывает требования к системе с точки зрения области применения -
“домена”. Соответственно, изложение требований в нем ведется в терминах
прикладной области. Документ описывает системные требования вместе с
не всегда бывает понятно из контекста). Как пример можно привести собственно
использование (и, что немаловажно, понимания!) термина «требования». Под этим
ёмким термином можно понимать как требования к бизнес процессам, так и
-функциональные или нефункциональные требования к ПО вообще. Интересно, что на
+функциональные или нефункциональные требования к ПО вообще. Интересно, что на
уровне многих стандартов (к сожалению, в основном, англоязычных) прописано
использование тех или иных глаголов, форм и структурирование предложений,
описывающих требования – например использование глаголов (will, shall, should,
реагирование является гарантировано приводит к успеху – сложно сказать. Более
того, если кто-то однозначно настаивает только на одной из идей и полностью
отвергает другую – это профанация. Восприятие изменений и возможность их
-своевременной обработки - вопрос способности проектной команды работать в
+своевременной обработки - вопрос способности проектной команды работать в
условиях постоянно меняющихся условий, принимаемых архитектурных решений и
многих других культурных, технологических и организационных факторов. Так или
иначе, понимание меняющейся природы требований – один из факторов адекватного
blob - 8527710f27d1b1221de2ea82d2256986da76e76b
blob + bdc5ac227824cb28fb126dd188f87fc415273ec7
--- 2_software_design.md
+++ 2_software_design.md
В результате консенсуса, принятого создателями SWEBOK, данная область знаний не
описывает все сущности или понятия, имеющие в своем названии слово “дизайн” или
“архитектура”. В 1999 году Том ДеМарко (Tom DeMarco) [DeMarco, 1999], один из
-известных специалистов в программной инженерии, предложил терминологическое
+известных специалистов в программной инженерии, предложил терминологическое
разделение различных видов дизайна:
- *D-дизайн (D-design, decomposition design)* – декомпозиция структуры
Значение оригинальных терминов очень близко и, в зависимости от контекста,
“связанность” и “соединение” могут рассматриваться как степень
самодостаточности или ее отсутствия (coupling) и функциональная зависимость
-(cohesion) , соответственно.
+(cohesion), соответственно.
Хочется особенно подчеркнуть значимость этих понятий, так как с развитием
сервисно-ориентированной архитектуры (Service-Oriented Architecture, SOA),
системе координат “вопрос-уровень детализации”. Каждое архитектурное
представление является результатом ответа на вопрос (Как? Что? Где? и т.п.) в
контексте необходимого уровня абстракции (содержание, то есть концепция:
-бизнес-модель, то есть функциональность и т.д.). Например, физическая модель
+бизнес-модель, то есть функциональность и т.д.). Например, физическая модель
данных (Physical Data Model) является ответом на вопрос “что?” в контексте
технологической модели, а логическая модель данных, отвечая на тот же вопрос,
находится на один уровень абстракции выше – в контексте системной или
ожиданий в отношении различных аспектов конкретного дизайна, например, размера
<проекта>, структуры (ее сложности) или качества (например, в контексте
требований, предъявляемых к производительности). Чаще всего, все метрики
-разделяют по двум категориям:
+разделяют по двум категориям:
- функционально-ориентированные
- объектно-ориентированные
для описания структур данных в терминах последовательности, выбора и итераций
(повторений);
- *Структурные схемы (Structure charts)*: описываю структуру вызовов в
-программах (какой модуль вызывает, кем и как вызываем).
+программах (какой модуль вызывает, кем и как вызываем).
[^2_2]: Здесь необходимо отметить различие в понятиях класса (или объекта) и
компонента: компонент рассматривается как физически реализуемый элемент
- *Диаграммы сотрудничества (Collaboration diagrams)*: показывают динамическое
взаимодействие, происходящее в группе объектов и уделяют особое внимание
объектам, связям между ними и сообщениям, которыми обмениваются объекты
-посредством этих связей;
+посредством этих связей;
- *Диаграммы потоков данных (Data flow diagrams, DFD)*: описывают потоки данных
внутри набора процессов (не в терминах процессов операционной среды, но в
понимании обмена информацией в бизнес-контексте);
blob - bc07a3d953b0e68f0923624f54523d9b70aa5fcb
blob + b4d02ad105bdcc99724e4fd1f7be67f28f2897dd
--- 3_software_construction.md
+++ 3_software_construction.md
областью знаний “Проектирование программного обеспечения”.
В свою очередь, на протяжении всей деятельности по конструированию, инженеры
-используют модульное и интеграционное тестирование. Таким образом связана
+используют модульное и интеграционное тестирование. Таким образом связана
данная область знаний с “Тестированием программного обеспечения”.
В процессе конструирования обычно создается большая часть активов программного
Другие модели более итеративны, к ним относятся – эволюционное
прототипирование, экстремальное программирование и Scrum. Эти подходы сходятся
-к рассмотрению конструирования как деятельности, которая ведется одновременно
+к рассмотрению конструирования как деятельности, которая ведется одновременно
с другими видами работ по созданию программного обеспечения и пересекаясь с
ними (видимо, здесь имеется в виду взаимозависимость и влияние друг на друга),
включая определение требований, проектирование и планирование. Эти подходы
blob - 4d10e0902e91ad00167f35909e7512d7837a4c3c
blob + a3c1209a8597fcd736662c66a220f06ce4c58c6a
--- 4_software_testing.md
+++ 4_software_testing.md
#### Таблицы принятия решений (Decision table)
Такие таблицы представляют логические связи между условиями (могут
-рассматриваться в качестве “входов”) и действиями (могут рассматриваться как
+рассматриваться в качестве “входов”) и действиями (могут рассматриваться как
“выходы”). Набор тестов строится последовательным рассмотрением всех возможных
кросс-связей в такой таблице.
blob - bc967963990b2b8a36cbfc7b94d5140347d2cc30
blob + 0c95dd4a427fbff9ddd17b879678be0e54ff91f2
--- 5_software_maintenance.md
+++ 5_software_maintenance.md
вопросам поддержки и сопровождения инфраструктуры информационных технологий). В
большой степени, как отмечает SWEBOK, это связано с сокращением инвестиций
организаций непосредственно в разработку программных систем, с целью увеличения
-сроков использования уже существующего и применяемого ПО. Конечно, с точки
+сроков использования уже существующего и применяемого ПО. Конечно, с точки
зрения автора, это не единственная причина. Скорее вопросы постоянно
изменяющихся бизнес-потребностей, динамика бизнеса и желание повысить отдачу от
уже эксплуатируемых систем приводит к усилению роли поддержки и сопровождения
решений. Это ни в коем случае не значит, что волна Open Source “захлебнулась”.
Это означает только, что игнорирование оценки стоимости сопровождения привело к
превышению бюджетов, недостатку ресурсов и, в конце концов, частому провалу
-инициатив по использованию таких продуктов в корпоративной среде. Неготовность
+инициатив по использованию таких продуктов в корпоративной среде. Неготовность
рассматривать жизненный цикл во времени как продолжающийся и после передачи
системы в эксплуатацию, непроработанность соответствующих процедур
корректировки продукта после его выпуска – основная беда и в бизнес-среде, для
протяжении всего периода эксплуатации удовлетворяет требованиям пользователей.
Деятельность по сопровождению применима для программного обеспечения,
созданного с использованием любой модели жизненного цикла (например,
-спиральной) и методологии разработки. На первый взгляд, это утверждение SWEBOK
+спиральной) и методологии разработки. На первый взгляд, это утверждение SWEBOK
может показаться тривиальным. Однако, обратитесь к своему опыту разработки и
использования различного программного обеспечения. Наверняка, Вы найдете случаи
из собственной практики или практики коллег, когда столь очевидное утверждение
сохранять необходимый уровень затрат, но и снижать их.
Существуют как технические, так и другие (например, организационные,
-являющиеся, по мнению автора, наиболее сильно влияющими на объем затрат)
+являющиеся, по мнению автора, наиболее сильно влияющими на объем затрат)
факторы, оказывающие влияние на стоимость сопровождения, в целом:
- тип приложения
процесса разработки необходимо специфицировать, оценивать и контролировать
характеристики, влияющие на возможность сопровождения. Если такие работы
проводятся регулярно, это облегчает дальнейшее сопровождение, повышая его
-сопровождаемость (в частности, как характеристику качества). Часто этого
+сопровождаемость (в частности, как характеристику качества). Часто этого
сложно добиться, потому, что, к сожалению, такого рода характеристики
игнорируются при разработки. Разработчики заняты другими запланированными
работами и также часто пренебрегают требованиями, предъявляемыми к
Недостаточно, всего лишь, надеяться, что в процессе и результате сопровождения,
качество программного обеспечения будет повышаться. Для поддержки процесса
-сопровождения должны планироваться и реализовываться соответствующие процедуры
+сопровождения должны планироваться и реализовываться соответствующие процедуры
и процессы, направленные на повышение качества. Работы и техники по обеспечению
качества (Software Quality Assurance, SQA), проверке и аттестации (V&V,
verification and validation), обзору, анализу и оценке (review), а также
другими процессами, направленными на достижение желаемого уровня качества.
SWEBOK, основываясь на стандарте ISO/IEC 14764 (Standard for Software
Engineering - Software Maintenance), рекомендует адаптировать соответствующие
-процессы, техники и активы, относящиеся к разработке программного обеспечения.
+процессы, техники и активы, относящиеся к разработке программного обеспечения.
К ним, например, относятся документация по тестированию и результаты тестов.
Дополнительные подробности можно найти в соответствующей области знаний
“Качество программного обеспечения” (Software Quality).
blob - 9e004e1f4f3c4dbe5f0fe79d6242fbbdc6633ed3
blob + 01eba18a1ccbc968cb8b2d354ce23219424b4946
--- 6_software_configuration_management.md
+++ 6_software_configuration_management.md
стандартах, выпущенных соответствующими стандартизирующими организациями.
Лучшие практики также отражены в моделях совершенствования и оценки процессов,
например, в CMMI – Capability Maturity Model Integration Института программной
-инженерии (SEI – Software Engineering Institute) университета Карнеги-Меллон
+инженерии (SEI – Software Engineering Institute) университета Карнеги-Меллон
(Carnegie-Mello University) и ISO/IEC 15504 (SPICE) “Software Engineering –
Process Assessment”.
SWEBOK обращает внимание (рекомендуя соответствующий первоисточник) на
следующие ключевые индикаторы: работы и прогресс <по их выполнению> (Work and
Progress) и индикаторы качества – поток изменений (Change Traffic),
-стабильность <конфигураций> (Stability), раздробленность (Breakage),
+стабильность <конфигураций> (Stability), раздробленность (Breakage),
модульность (Modularity), переработка (Rework), адаптируемость (Adaptibility),
среднее время между сбоями (MTBF – Mean Time Between Failures),
зрелость/полнота <информации> (Maturity). Отчетность по этим индикаторам может
![Рисунок 3. Характеристики SCM-инструментов и связанные процедуры. [SWEBOK, 2004, с.7-4, рис. 3]](images/configuration_management_3-tools_and_processes.jpg)
В этом примере система управления кодом поддерживает программные библиотеки
-контролируя доступ к элементам библиотек, координирует действия множества
+контролируя доступ к элементам библиотек, координирует действия множества
пользователей и помогает в проведении рабочих процедур. Другие инструменты
поддерживают процесс сборки и выпуска программного обеспечения и документации
на основе программных элементов, содержащихся в библиотеках. Инструменты для
Первый шаг по управлению изменениями контролируемых элементов состоит в
определении того, какие именно изменения надо производить. Процесс обработки
запросов на изменения (software change request process), представленный на
-рисунке 5, включает формальные процедуры по предложению (submitting) и записи
+рисунке 5, включает формальные процедуры по предложению (submitting) и записи
(recording) запросов на изменения, оценки потенциальной стоимости и влияния
предлагаемых изменений, а также принятию, модификации или отказу от внесенных
предложений по изменениям. Запросы на изменения элементов программных
работ <программной инженерии>, как и спецификации, созданные в процессе
разработки, могут содержать условия, которые не могут быть удовлетворены в
заданной точке жизненного цикла. Отклонение (deviation) - утверждение
-изменений, внесенных относительно предварительно сформулированных условий к
+изменений, внесенных относительно предварительно сформулированных условий к
разработке тех или иных аспектов разработки заданных элементов. Отказ (waiver)
– утверждение дальнейшего использования элемента, которое отличается в той или
иной степени от предварительно заданных условий. В обоих случаях используются
критически-важного программного обеспечения): функциональный аудит конфигураций
(Functional Configuration Audit, FCA) и физический аудит конфигураций (Physical
Configuration Audit, PCA). Успешное (в терминах соответствия результатов
-заданным условиям) завершение этих аудитов может быть обязательным требованиям
+заданным условиям) завершение этих аудитов может быть обязательным требованиям
для фиксирования базовой линии продукта. В то же время, если сравнивать
контекст FCA и PCA для программного и аппаратного обеспечения, перед их
выполнением необходимо четко оценивать реальные потребности в таких видах
различные версии для разных платформ или редакции с различным набором
функциональных возможностей), часто бывает необходимо создавать
специализированные версии и пакеты (сборки) соответствующих материалов
-(элементов, активов) для выпуска в качестве <самостоятельной> версии.
+(элементов, активов) для выпуска в качестве <самостоятельной> версии.
Программная библиотека (предоставляющая соответствующий инструментарий для
такой сборки) играет ключевую роль в выполнении таких работ.
Для поддержки таких функций управления выпуском могут требоваться
соответствующие возможности инструментария поддержки (средств поддержки или
“вспомогательных средств”, если, например, попытаться максимально приблизиться
-к русскоязычной терминологии ГОСТ 12207). Также полезна и связь с
+к русскоязычной терминологии ГОСТ 12207). Также полезна и связь с
инструментальными возможностями поддержки процесса обработки запросов на
изменения для отображения содержимого релиза на полученные запросы на изменения
(SCR - software change request, включая сообщения об обнаруженных ранее и
blob - 3ee2cd12d511378445c09aaccc36d928f4ff3f1c
blob + 000adcbe06357fbc4c9a75e144a68501989a038f
--- 7_software_engineering_management.md
+++ 7_software_engineering_management.md
Крайне необходимо выделить как самостоятельную тему данной секции вопросы
управления персоналом – people management, уделив особое внимание аспектам
-экспертизы (не стоит путать с ролями/обязанностями) и лидерства специалистов в
+экспертизы (не стоит путать с ролями/обязанностями) и лидерства специалистов в
проектной команде. К этой же теме, также стоит отнести вопросы обучения,
прохождения тренингов специалистами проектной команды. Наконец, к теме ресурсов
имеет непосредственное отношение и определение необходимости и объема
### Процесс мониторинга (Monitor Process)
Соблюдение плана проверяется постоянно и через предопределенные интервалы
-времени. Анализируются выходы (outputs) и условия завершения <задач>.
+времени. Анализируются выходы (outputs) и условия завершения <задач>.
Получаемые <в процессе измерений> результаты оцениваются в терминах требуемых
характеристик (например, через процедуры обзора/оценки и аудита – review,
audit). Затраты усилий (efforts), соблюдения расписания, стоимость к данному
необходимые для реализации процесса ведения измерений, а также включающий
информационную модель измерений.
-* “действия/работы” - activities, “задачи” – tasks: термин “задача”
+* “действия/работы” - activities, “задачи” – tasks: термин “задача”
используется для более глубокого уровня детализации, чем “действия/работы”;
термины “действия” и “работы”, как вы уже заметили, часто используются
взаимозаменяемым образом. Так или иначе, это вопрос договоренности о
должны быть оценены количественно, с тем, чтобы проект могу быть управляем в
процессе достижения заданного результата. Для этого необходимо:
- - Определить содержание измерений. Необходимость принять, в каких масштабах –
+ - Определить содержание измерений. Необходимость принять, в каких масштабах –
на уровне какой организационной единицы* будут проводиться измерения – только в
одной функциональной области, в рамках проекта, на уровне комплекса проектов
или в организации, в целом. Все последующие задачи по ведению измерений,
приоритетов информационных потребностей и других критериев – таких, как
стоимость сбора данных, возможность срыва процессных работ при сборе данных
(например, в силу недостатка ресурсов), легкость анализа, легкость получения
-точных и целостных данных и т.п. (см. стандарт ISO 15939-02, раздел 5.2.3 и
+точных и целостных данных и т.п. (см. стандарт ISO 15939-02, раздел 5.2.3 и
приложение C).
- Определение наборов <собираемых> данных, а также процедур анализа и ведения
отчетности. Это включает в себя коллекцию процедур и расписаний, хранение,
blob - e263e64b60344ce254d11b107883c7cb2097a5cb
blob + 2220ace2390d547db17e338f5299c1d99254e626
--- 8_software_engineering_process.md
+++ 8_software_engineering_process.md
другие специализированные организационные структуры и органы, в общем случае
называемые steering committee – “управляющий комитет”, обладающий
наблюдательными функциями в отношении усилий, направленных на мониторинг,
-контроль и выработку рекомендаций по поддержке и улучшению процесса
+контроль и выработку рекомендаций по поддержке и улучшению процесса
программной инженерии. На основе таких функций будем в дальнейшем использовать
термин “наблюдательный орган”, подчеркивая реальные задачи такой комиссии и
возможность как формальной, так и неформальной его организации.
Основной задачей EF является институализация (внедрение в повседневную
практику) коллективного опыта и полученных уроков в масштабах организации на
основе разработки, обновления и внедрения в проектную организацию “пакетов
-опыта” – experience packages (например, руководств, моделей, курсов обучения и
+опыта” – experience packages (например, руководств, моделей, курсов обучения и
т.п.), <типовых> “активов процесса” – process assets. Проектная организация
предлагает на рассмотрение EF свои продукты, планы, использовавшиеся при
разработке, а также данные, собранные в процессе разработки и эксплуатации.
### Цикл управления программным процессом (Software Process Management Cycle)
Управление процессами в области программного обеспечения состоит из четырех
-действий, представленных в рамках итеративного цикла. Это позволяет получать и
+действий, представленных в рамках итеративного цикла. Это позволяет получать и
анализировать отклики на постоянной основе и, <более оперативно>
совершенствовать процесс. Вот эти четыре действия, предлагаемые SWEBOK:
детального определения, но концентрируется на ключевых работах и их
взаимосвязях. Примерами таких моделей[^8_1] являются водопадная
(каскадная - waterfall), модель прототипирования, эволюционной разработки,
-инкрементальная/итеративная, спиральная и т.п. Существуют различные сравнения
+инкрементальная/итеративная, спиральная и т.п. Существуют различные сравнения
и критерии выбора моделей, ссылки на некоторые из которых, в частности, даны в
оригинальной версии SWEBOK.
В определенной степени, CMMI (и аналогичные модели в области управления
проектами, например, PMI OPM3 и менеджмента качества, например, Six Sigma)
-предоставляют обоснованный и подтвержденный базис для использования эталонной
+предоставляют обоснованный и подтвержденный базис для использования эталонной
техники.
blob - 721310bd30d4909e5fb51c6d4aa561a90290eb19
blob + e311e627c1976f443babe458b440e4f91c5d2a8e
--- 9_software_engineering_tools_and_methods.md
+++ 9_software_engineering_tools_and_methods.md
тестирования и др., соответствующие, различным целям тестирования,
представленным в секции 2.2 области знаний SWEBOK “Тестирование”, и естественно
задающим “подвиды” возможного класса “специализированных или целевых
-инструментов тестирования”, к которым, в частности, относится тестирование
+инструментов тестирования”, к которым, в частности, относится тестирование
производительности.
### Инструменты сопровождения (Software Maintenance Tools)
## Методы программной инженерии (Software Engineering Methods)
-Данная секция (подобласть) разделена на три темы: эвристические методы
+Данная секция (подобласть) разделена на три темы: эвристические методы
(heuristic methods), касающиеся неформализованных подходов; формальные методы
(formal methods), обоснованные математически; методы прототипирования
(prototyping methods), базирующиеся на различных формах прототипирования. Эти
blob - ca52057605bb170091b6e1bfa7851f6f05ec90eb
blob + bba382687a04421fd3bed7043660c325497e2cfe
--- bibliography.md
+++ bibliography.md
- [Арчибальд, 2003] – Рассел Д. Арчибальд. Управление высоко-технологичными
программами и проектами. Издание третье, переработанное и дополненное. John
Wiley & Sons, Inc. (ISBN 0-471-26557-8) 1976 – Russel D. Archibald, 2003;
-перевод и издание на русском языке: АйТи (ISBN 5-98453-002-3) - ДМК Пресс
+перевод и издание на русском языке: АйТи (ISBN 5-98453-002-3) - ДМК Пресс
(ISBN 5-94074-214-9) 2004.
- [Арчибальд, 2005] – Рассел Д. Арчибальд. Искусство управления проектами:
состояние и перспективы. Возможности и уровень зрелости организации в
программные системы. 2-е издание, юбилейное. Addison-Wesley Longman, Inc. (ISBN
0-201-83595-9), 1995. Издательство Символ-Плюс (ISBN 5-93286-005-7), 2000, 2005.
- [Вигерс, 2003] – Карл И. Вигерс. Разработка требований к программному
-обеспечению. Издательско-торговый дом “Русская редакция”, перевод на русский
+обеспечению. Издательско-торговый дом “Русская редакция”, перевод на русский
язык второй редакции книги – Microsoft Corporation (ISBN 5-7502-0240-2), 2004.
Оригинальное издание на английском языке: 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, Государственный Стандарт
blob - 55e2a537d348d29f796ecf68a1f36d458c2094d6
blob + 5dbe36c867b957748fef5d4d9e60e8a6ec720c6f
--- software_lifecycle_models.md
+++ software_lifecycle_models.md
Стандарт отмечает, что работы проводятся с использованием проектного подхода и
могут пересекаться по времени, т.е. проводиться одновременно или с наложением,
-а также могут предполагать рекурсию и разбиение на итерации.
+а также могут предполагать рекурсию и разбиение на итерации.
#### Эксплуатация (5.4)
Важно понимать, что стандарт 12207 не определяет последовательность и разбиение
выполнения процессов во времени, адресуя этот вопрос также работам по адаптации
стандарта к конкретным условиям и окружению и применению выбранных моделей,
-практик, техник и т.п.
+практик, техник и т.п.
### Адаптация стандарта
* Необходимо отметить, что существует еще один стандарт жизненного цикла -
ISO/IEC 15288 (выпущен в 2002 году), фокусирующийся на вопросах организации
процессов жизненного цикла системного уровня (Life Cycle Processes – System) и
-включающий специальный процесс - “Tailoring”, т.е. настройку, адаптацию
+включающий специальный процесс - “Tailoring”, т.е. настройку, адаптацию
жизненного цикла к конкретным требованиям и ограничениям, существующим или
принятым в конкретной организации/подразделении или для заданного проекта.
