commit 8f334207e4e7e15a406d129993b67cf9b714f068 from: Sergey Bronnikov date: Tue Jun 04 08:41:59 2024 UTC Remove extra whitespaces commit - 48c63dee92b321ed49c64cb7a2b481a47e98d6af commit + 8f334207e4e7e15a406d129993b67cf9b714f068 blob - c3f385153806b2b312ff8d616ab8ba9089e5de3f blob + c939f8b657bead938bc491a82f4f4d6fdefb72e2 --- 0_introduction.md +++ 0_introduction.md @@ -41,7 +41,7 @@ Software Engineering: Version* - Руководство к Своду Знаний по Программной Инженерии, в дальнейшем просто “SWEBOK” [SWEBOK, 2004]; - *Software Engineering 2004. Curriculum Guidelines for Undergraduate Degree -Programs in Software Engineering* – Учебный План для Преподавания Программной +Programs in Software Engineering* – Учебный План для Преподавания Программной Инженерии в ВУЗах (данное название на русском языке представлено в вольном смысловом переводе) [SE, 2004]. @@ -187,7 +187,7 @@ SWEBOK – “секций” и дает декомп ![Рисунок 3-а. Области знаний связанных дисциплин на английском языке](images/swe_other-ka_en.jpg) -![Рисунок 3-б. Области знаний связанных дисциплин на русском языке](images/swe_other-ka_ru.jpg) +![Рисунок 3-б. Области знаний связанных дисциплин на русском языке](images/swe_other-ka_ru.jpg) ## Перевод SWEBOK на русский язык blob - d02266df811e2001676eccdd567227e02abcad4c blob + 96051e5bc4d4a912e60d498a0512e7670aaa351b --- 10_software_quality.md +++ 10_software_quality.md @@ -33,7 +33,7 @@ Quality Program”, http://www.quality.nist.gov) ис противопоставляется “качеству, диктуемому заказчиком”. Конечно, не стоит и проводить параллель “приемлемого качества” с “продуктом второй свежести”. Введение категории “приемлемости” в отношении качества является лишь -прагматичным взглядом на желаемую степень совершенства создаваемого продукта +прагматичным взглядом на желаемую степень совершенства создаваемого продукта (услуги), способную удовлетворить пользователей и достижимую в рамках заданных проектных ограничений. Интересно, что и сама “степень приемлемости” также выступает в роли ограничения проекта, а в приложении к индустрии программного @@ -41,7 +41,7 @@ Quality Program”, http://www.quality.nist.gov) ис от управления требованиями (“атрибуты качества” как категория нефункциональных требований), до тестирования (т.н. наработка на отказ, такие метрики как MTTF - Mean Time To Failure, то есть среднее время между обнаруженными сбоями системы, -и т.п. ). В какой-то степени, “приемлемое качество” можно сравнивать с уровнем +и т.п.). В какой-то степени, “приемлемое качество” можно сравнивать с уровнем обслуживания в рамках заданного SLA – Service Level Agreement, давно уже принятого на вооружение в телекоммуникационной индустрии. Таким образом, приемлемое качество может рассматриваться как <количественно выраженный> @@ -152,7 +152,7 @@ failure cost). планирования, (адаптации) и оценки качества программных продуктов. ISO/IEC определяет три связанных модели качества программного обеспечения (ISO 9126-01 Software Engineering - Product Quality, Part 1: Quality Model) – внутреннее -качество, внешнее качество и качество в процессе эксплуатации, а также набор +качество, внешнее качество и качество в процессе эксплуатации, а также набор соответствующих работ по оценке качества программного обеспечения (ISO14598-98 Software Product Evaluation). @@ -188,7 +188,7 @@ Guidelines for the Application of ISO9001:2000 to Comp Software Process Assessment”, известный как SPICE - Software Process Improvement and Capability dEtermination, который также рассматривается в упомянутой области знаний). Непосредственно с управлением качеством связаны -процессные области (области компетенции) CMMI: обеспечение качества процесса и +процессные области (области компетенции) CMMI: обеспечение качества процесса и продукта (process and product quality assurance, категория процессов CMMI “Support”), проверка (verification, категория “Engineering”) и аттестация (validation, категория “Engineering”). При этом, CMMI классифицирует обзор @@ -237,7 +237,7 @@ requirements specification, SRS), модели, код Качество программного обеспечения может повышаться за счет итеративного процесса постоянного улучшения. Это требует контроля, координации и обратной связи в процессе управления многими одновременно выполняемыми процессами: (1) -процессами жизненного цикла, (2) процессом обнаружения, устранения и +процессами жизненного цикла, (2) процессом обнаружения, устранения и предотвращения сбоев/дефектов и (3) процессов улучшения качества. К программной инженерии применимы теории и концепции, лежащие в основе @@ -271,7 +271,7 @@ quality”. Эти концепции основыва Управление качеством программного обеспечения (SQM, Software Quality Management) применяется ко всем аспектам процессов, продуктов и ресурсов. SQM -определяет процессы, владельцев процессов, а также требования к процессам, +определяет процессы, владельцев процессов, а также требования к процессам, измерения процессов и их результатов, плюс – каналы обратной связи. Процессы управления качеством содержат много действий. Некоторые из них @@ -660,7 +660,7 @@ Classification of Software Anomalies”) и оцени Гарантоспособность (dependability) программного обеспечения включает такие характеристики, как защищенность от сбоев (fault-tolerance), безопасность использования (safety – безопасность в контексте приемлемого риска для здоровья -людей, бизнеса, имущества и т.п. ), информационная безопасность или +людей, бизнеса, имущества и т.п.), информационная безопасность или защищенность (security – защита информации от несанкционированных операций, включая доступ на чтение, а также гарантия доступности информации авторизованным пользователям, в объеме заданных для них прав), а также удобство @@ -670,7 +670,7 @@ Classification of Software Anomalies”) и оцени Quality Model”). В обсуждении данного вопроса существенную роль играет обширная литература по -системам повышенной надежности. При этом, применяется терминология, пришедшая +системам повышенной надежности. При этом, применяется терминология, пришедшая из области традиционных механических и электрических систем (в т.ч. не включающих программное обеспечение) и описывающая концепции опасности, рисков, целостности систем и т.п. SWEBOK приводит ряд источников, где подробно @@ -708,7 +708,7 @@ Quality Model”). SQM-процессы обеспечивают нахождение дефектов. Описание характеристик дефектов играет основную роль в понимании продукта, облегчает корректировку процесса или -продукта, а также информирует менеджеров проектов и заказчиков о статусе +продукта, а также информирует менеджеров проектов и заказчиков о статусе (состоянии) процесса или продукта. Существуют множество таксономий (классификации и методов структурирования) дефектов (сбоев). На сегодняшний день нет четкого консенсуса по этому вопросу и SWEBOK приводит некоторые @@ -723,7 +723,7 @@ SQM-процессы обеспечивают нахо требует огромных усилий по интерпретации (и корректировке) ранее определенных классов дефектов (сбоев). При отслеживании дефектов инженер интересуется не только их количеством, но и типом. Данный аспект (а именно, распределение -дефектов по типам) особенно важен для определения наиболее слабых элементов +дефектов по типам) особенно важен для определения наиболее слабых элементов системы, с точки зрения используемых технологий и архитектурных решений, что приводит к необходимости их углубленного изучения, создания специализированных пилотных проектов, дополнительной проверки концепции (proof of concept, POC – @@ -896,7 +896,7 @@ analysis) и алгоритмический анали В процессе разработки и сопровождения программного обеспечения приходится обращаться к различным видам динамических техник. В основном, это техники тестирования. Однако, в качестве динамических техник могут рассматриваться -техники симуляции, проверки моделей и “символического” исполнения (symbolic +техники симуляции, проверки моделей и “символического” исполнения (symbolic execution, часто предполагает использование модулей-“пустышек” с точки зрения выполняемой логики, с эмулируемым входом и выходом при рассмотрении общего сценария поведения многомодульных систем; иногда под этим термином понимаются и blob - a15a319d076751d052bb1fed09b0e1f4218801a3 blob + 5fd15c46c15df89c024f789cc4c29baff0c34108 --- 1_software_requirements.md +++ 1_software_requirements.md @@ -75,7 +75,7 @@ Glossary Of Software Engineering Terminology, 1990): достижения целей. - Условие или возможность, которые должны удовлетворяться системой/компонентом системы или которыми система/компонент системы должна обладать для обеспечения -условий контракта, стандартов, спецификаций или др. регулирующими документами. +условий контракта, стандартов, спецификаций или др. регулирующими документами. - Документальная репрезентация (зафиксированное представление, определение, описание) условий или возможностей, перечисленных в предыдущих пунктах. @@ -189,7 +189,7 @@ Modeling. Все бизнес-правила, в ра В настоящее время разработаны методы и подходы формального представления бизнес-правил, вплоть до формальных языков описания (использование OCL – Object -Constraint Language, BRML – Business Rules Markup Language). +Constraint Language, BRML – Business Rules Markup Language). Бизнес-правила могут быть не только использованы при определении требований к разрабатываемому ПО, но и могут отдельно оформляться в дизайне ПО (класс или @@ -223,7 +223,7 @@ agile-техниках, например, FDD – Feat Вигерс, описывает feature как “множество логически связанных функциональных требований, которые предоставляют определенные возможности для пользователя и удовлетворяют бизнес-целям <организации>”. С точки зрения маркетинга -программного обеспечения, как отмечает Вигерс, feature это «группа требований, +программного обеспечения, как отмечает Вигерс, feature это «группа требований, узнаваемая заинтересованными лицами, которые вовлечены в процесс принятия решения по приобретению ПО – это список <отличительных особенностей или возможностей, характеристик>, присутствующий в описании продукта». В то же @@ -231,14 +231,14 @@ agile-техниках, например, FDD – Feat 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 могут быть как относящимся к функциональным, так и к нефункциональным требованиям. И @@ -301,11 +301,11 @@ kshell (популярной командной обо прототипу пользовательского интерфейса на этапе опытной эксплуатации. Такие требования должны однозначно отвечать на вопросы, предполагающие ответы с -численными величинами – как часто? насколько быстро? в каком количестве? и т.п. +численными величинами – Как часто? Насколько быстро? В каком количестве? и т.п. Большинство требований с количественной оценкой относится к атрибутам качества. -В качестве примера можно привести реальное требование, присутствующее в +В качестве примера можно привести реальное требование, присутствующее в реальном проекте по электронному документообороту: “Система должна производить поиск документов <определенного вида> за время, не превышающее 5 секунд”. Это типичное требование с количественной оценкой, в котором определена верхняя @@ -480,7 +480,7 @@ SWEBOK особо подчеркивает, что е Техническое задание по ГОСТ. Но действительно ли в этом документе можно увидеть требования – увы. Следуя только рекомендациям, которые есть в ГОСТ можно только соответствующим образом оформить разделы, что практически никак не влияет на -качество и информативность документа. Вопросы совершенствования процессов – +качество и информативность документа. Вопросы совершенствования процессов – process improvement будут рассматриваться как в главах, посвященных CMMI, так и в других частях этой книги. @@ -560,7 +560,7 @@ Engineering Process). В этом контексте, процессы сбора требований, а сами требования – “выходом” этих процессов; - Сценарии – контекст для сбора пользовательских требований, определяющий ответы на вопросы “что если” и “как это делается” в отношении бизнес-процессов, -реализуемых пользователями; +реализуемых пользователями; - Прототипы – отличный инструмент для уточнения и/или детализации требований; существуют разные подходы к прототипированию – от “бумажных” моделей до пилотных подсистем, реализуемых как самостоятельные (в терминах управления @@ -589,7 +589,7 @@ Engineering Process). В этом контексте, аналитиков и инженеров рядом с пользователем в процессе выполнения последним его работ по обеспечению функционирования бизнес-процессов: в определенной степени можно провести аналогию с практикой присутствия представителя заказчика -в проектной группе исполнителя ( типовая практика в eXtreme Programming +в проектной группе исполнителя (типовая практика в eXtreme Programming “on-site customer” – “присутствующий заказчик”); данная техника является достаточно затратной, но, в то же время, очень эффективной, а иногда – просто незаменимой, особенно, если речь идет о достаточно сложных и взаимосвязанных @@ -666,7 +666,7 @@ SADT – Structured Analysis and Design Technique (м красивыми квадратиками со стрелочками”. Ни то, ни другое утверждение неверны. Например, в XP и в других гибких (Agile) практиках существуют и истории пользователей, и карточки задач, и процедуры анализа (в частности, связанных с -ними “мозговых штурмов”, как запланированных, так и, к сожалению, не очень) , в +ними “мозговых штурмов”, как запланированных, так и, к сожалению, не очень), в результате которого мы сформулировали задачи, высокоуровневые возможности - “фичи” продукта (feature - особенность), а также необходимые модели (см. [Амблер, 2002]). Объем моделей, их детализация и средства представления могут @@ -706,8 +706,8 @@ SADT – Structured Analysis and Design Technique (м группах – статические модели и поведенческие), связанных и объединенных общей архитектурой, на основе концепции метамоделей. -Cовременное состояние стандарта UML (унифицированного языка моделирования -Unified Modeling Language, разрабатываемого консорциумом OMG – www.omg.org ) +Современное состояние стандарта UML (унифицированного языка моделирования +Unified Modeling Language, разрабатываемого консорциумом OMG – www.omg.org) версии 2.0 вполне позволяет говорить о расширении его применимости в “чистом” бизнес-моделировании. На фоне богатства выразительных средств, появления соответствующего инструментального обеспечения работы с UML 2.0, длительной @@ -796,7 +796,7 @@ Requirements for Enterprise-Reference Architectures an требований” (user requirements specification) или “концепция” (concept ), описывает системные требования. Содержание документа определяет высокоуровневые требования, часто – стратегические цели, для достижения которых -создается программная система. Принципиальным моментом является то, что такой +создается программная система. Принципиальным моментом является то, что такой документ описывает требования к системе с точки зрения области применения - “домена”. Соответственно, изложение требований в нем ведется в терминах прикладной области. Документ описывает системные требования вместе с @@ -871,7 +871,7 @@ Requirements Specifications”. не всегда бывает понятно из контекста). Как пример можно привести собственно использование (и, что немаловажно, понимания!) термина «требования». Под этим ёмким термином можно понимать как требования к бизнес процессам, так и -функциональные или нефункциональные требования к ПО вообще. Интересно, что на +функциональные или нефункциональные требования к ПО вообще. Интересно, что на уровне многих стандартов (к сожалению, в основном, англоязычных) прописано использование тех или иных глаголов, форм и структурирование предложений, описывающих требования – например использование глаголов (will, shall, should, @@ -1078,7 +1078,7 @@ Testing) в описании 2.2.4 “Тесты со реагирование является гарантировано приводит к успеху – сложно сказать. Более того, если кто-то однозначно настаивает только на одной из идей и полностью отвергает другую – это профанация. Восприятие изменений и возможность их -своевременной обработки - вопрос способности проектной команды работать в +своевременной обработки - вопрос способности проектной команды работать в условиях постоянно меняющихся условий, принимаемых архитектурных решений и многих других культурных, технологических и организационных факторов. Так или иначе, понимание меняющейся природы требований – один из факторов адекватного blob - 8527710f27d1b1221de2ea82d2256986da76e76b blob + bdc5ac227824cb28fb126dd188f87fc415273ec7 --- 2_software_design.md +++ 2_software_design.md @@ -35,7 +35,7 @@ top-level design) – описание высокоу В результате консенсуса, принятого создателями SWEBOK, данная область знаний не описывает все сущности или понятия, имеющие в своем названии слово “дизайн” или “архитектура”. В 1999 году Том ДеМарко (Tom DeMarco) [DeMarco, 1999], один из -известных специалистов в программной инженерии, предложил терминологическое +известных специалистов в программной инженерии, предложил терминологическое разделение различных видов дизайна: - *D-дизайн (D-design, decomposition design)* – декомпозиция структуры @@ -144,7 +144,7 @@ FP-дизайн. I-дизайн в большей ст Значение оригинальных терминов очень близко и, в зависимости от контекста, “связанность” и “соединение” могут рассматриваться как степень самодостаточности или ее отсутствия (coupling) и функциональная зависимость -(cohesion) , соответственно. +(cohesion), соответственно. Хочется особенно подчеркнуть значимость этих понятий, так как с развитием сервисно-ориентированной архитектуры (Service-Oriented Architecture, SOA), @@ -309,7 +309,7 @@ SWEBOK не дает явного определени системе координат “вопрос-уровень детализации”. Каждое архитектурное представление является результатом ответа на вопрос (Как? Что? Где? и т.п.) в контексте необходимого уровня абстракции (содержание, то есть концепция: -бизнес-модель, то есть функциональность и т.д.). Например, физическая модель +бизнес-модель, то есть функциональность и т.д.). Например, физическая модель данных (Physical Data Model) является ответом на вопрос “что?” в контексте технологической модели, а логическая модель данных, отвечая на тот же вопрос, находится на один уровень абстракции выше – в контексте системной или @@ -433,7 +433,7 @@ mediator, memento, observer, state, strategy, template ожиданий в отношении различных аспектов конкретного дизайна, например, размера <проекта>, структуры (ее сложности) или качества (например, в контексте требований, предъявляемых к производительности). Чаще всего, все метрики -разделяют по двум категориям: +разделяют по двум категориям: - функционально-ориентированные - объектно-ориентированные @@ -497,7 +497,7 @@ IDL)*: языки, подобные языкам пр для описания структур данных в терминах последовательности, выбора и итераций (повторений); - *Структурные схемы (Structure charts)*: описываю структуру вызовов в -программах (какой модуль вызывает, кем и как вызываем). +программах (какой модуль вызывает, кем и как вызываем). [^2_2]: Здесь необходимо отметить различие в понятиях класса (или объекта) и компонента: компонент рассматривается как физически реализуемый элемент @@ -517,7 +517,7 @@ IDL)*: языки, подобные языкам пр - *Диаграммы сотрудничества (Collaboration diagrams)*: показывают динамическое взаимодействие, происходящее в группе объектов и уделяют особое внимание объектам, связям между ними и сообщениям, которыми обмениваются объекты -посредством этих связей; +посредством этих связей; - *Диаграммы потоков данных (Data flow diagrams, DFD)*: описывают потоки данных внутри набора процессов (не в терминах процессов операционной среды, но в понимании обмена информацией в бизнес-контексте); blob - bc07a3d953b0e68f0923624f54523d9b70aa5fcb blob + b4d02ad105bdcc99724e4fd1f7be67f28f2897dd --- 3_software_construction.md +++ 3_software_construction.md @@ -31,7 +31,7 @@ Testing). Причиной этого является областью знаний “Проектирование программного обеспечения”. В свою очередь, на протяжении всей деятельности по конструированию, инженеры -используют модульное и интеграционное тестирование. Таким образом связана +используют модульное и интеграционное тестирование. Таким образом связана данная область знаний с “Тестированием программного обеспечения”. В процессе конструирования обычно создается большая часть активов программного @@ -214,7 +214,7 @@ Process). Другие модели более итеративны, к ним относятся – эволюционное прототипирование, экстремальное программирование и Scrum. Эти подходы сходятся -к рассмотрению конструирования как деятельности, которая ведется одновременно +к рассмотрению конструирования как деятельности, которая ведется одновременно с другими видами работ по созданию программного обеспечения и пересекаясь с ними (видимо, здесь имеется в виду взаимозависимость и влияние друг на друга), включая определение требований, проектирование и планирование. Эти подходы blob - 4d10e0902e91ad00167f35909e7512d7837a4c3c blob + a3c1209a8597fcd736662c66a220f06ce4c58c6a --- 4_software_testing.md +++ 4_software_testing.md @@ -413,7 +413,7 @@ TDD. Насколько это верно, завис #### Таблицы принятия решений (Decision table) Такие таблицы представляют логические связи между условиями (могут -рассматриваться в качестве “входов”) и действиями (могут рассматриваться как +рассматриваться в качестве “входов”) и действиями (могут рассматриваться как “выходы”). Набор тестов строится последовательным рассмотрением всех возможных кросс-связей в такой таблице. blob - bc967963990b2b8a36cbfc7b94d5140347d2cc30 blob + 0c95dd4a427fbff9ddd17b879678be0e54ff91f2 --- 5_software_maintenance.md +++ 5_software_maintenance.md @@ -30,7 +30,7 @@ ITIL[^5_1] – IT Infrastructure Library, уделяю вопросам поддержки и сопровождения инфраструктуры информационных технологий). В большой степени, как отмечает SWEBOK, это связано с сокращением инвестиций организаций непосредственно в разработку программных систем, с целью увеличения -сроков использования уже существующего и применяемого ПО. Конечно, с точки +сроков использования уже существующего и применяемого ПО. Конечно, с точки зрения автора, это не единственная причина. Скорее вопросы постоянно изменяющихся бизнес-потребностей, динамика бизнеса и желание повысить отдачу от уже эксплуатируемых систем приводит к усилению роли поддержки и сопровождения @@ -55,7 +55,7 @@ Source во всем мире и связанная с решений. Это ни в коем случае не значит, что волна Open Source “захлебнулась”. Это означает только, что игнорирование оценки стоимости сопровождения привело к превышению бюджетов, недостатку ресурсов и, в конце концов, частому провалу -инициатив по использованию таких продуктов в корпоративной среде. Неготовность +инициатив по использованию таких продуктов в корпоративной среде. Неготовность рассматривать жизненный цикл во времени как продолжающийся и после передачи системы в эксплуатацию, непроработанность соответствующих процедур корректировки продукта после его выпуска – основная беда и в бизнес-среде, для @@ -214,7 +214,7 @@ R&D – Research and Development). При этом, р протяжении всего периода эксплуатации удовлетворяет требованиям пользователей. Деятельность по сопровождению применима для программного обеспечения, созданного с использованием любой модели жизненного цикла (например, -спиральной) и методологии разработки. На первый взгляд, это утверждение SWEBOK +спиральной) и методологии разработки. На первый взгляд, это утверждение SWEBOK может показаться тривиальным. Однако, обратитесь к своему опыту разработки и использования различного программного обеспечения. Наверняка, Вы найдете случаи из собственной практики или практики коллег, когда столь очевидное утверждение @@ -277,7 +277,7 @@ R&D – Research and Development). При этом, р сохранять необходимый уровень затрат, но и снижать их. Существуют как технические, так и другие (например, организационные, -являющиеся, по мнению автора, наиболее сильно влияющими на объем затрат) +являющиеся, по мнению автора, наиболее сильно влияющими на объем затрат) факторы, оказывающие влияние на стоимость сопровождения, в целом: - тип приложения @@ -538,7 +538,7 @@ Quality – Part 1: Quality Model, 2001 г.) опре процесса разработки необходимо специфицировать, оценивать и контролировать характеристики, влияющие на возможность сопровождения. Если такие работы проводятся регулярно, это облегчает дальнейшее сопровождение, повышая его -сопровождаемость (в частности, как характеристику качества). Часто этого +сопровождаемость (в частности, как характеристику качества). Часто этого сложно добиться, потому, что, к сожалению, такого рода характеристики игнорируются при разработки. Разработчики заняты другими запланированными работами и также часто пренебрегают требованиями, предъявляемыми к @@ -1003,7 +1003,7 @@ SCM-процесса обеспечивается ра Недостаточно, всего лишь, надеяться, что в процессе и результате сопровождения, качество программного обеспечения будет повышаться. Для поддержки процесса -сопровождения должны планироваться и реализовываться соответствующие процедуры +сопровождения должны планироваться и реализовываться соответствующие процедуры и процессы, направленные на повышение качества. Работы и техники по обеспечению качества (Software Quality Assurance, SQA), проверке и аттестации (V&V, verification and validation), обзору, анализу и оценке (review), а также @@ -1011,7 +1011,7 @@ verification and validation), обзору, анали другими процессами, направленными на достижение желаемого уровня качества. 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 @@ -196,7 +196,7 @@ Systems of Nuclear Power Plants”, U.S. Nuclear Regul стандартах, выпущенных соответствующими стандартизирующими организациями. Лучшие практики также отражены в моделях совершенствования и оценки процессов, например, в CMMI – Capability Maturity Model Integration Института программной -инженерии (SEI – Software Engineering Institute) университета Карнеги-Меллон +инженерии (SEI – Software Engineering Institute) университета Карнеги-Меллон (Carnegie-Mello University) и ISO/IEC 15504 (SPICE) “Software Engineering – Process Assessment”. @@ -272,7 +272,7 @@ SCM-деятельность поддерживает SWEBOK обращает внимание (рекомендуя соответствующий первоисточник) на следующие ключевые индикаторы: работы и прогресс <по их выполнению> (Work and Progress) и индикаторы качества – поток изменений (Change Traffic), -стабильность <конфигураций> (Stability), раздробленность (Breakage), +стабильность <конфигураций> (Stability), раздробленность (Breakage), модульность (Modularity), переработка (Rework), адаптируемость (Adaptibility), среднее время между сбоями (MTBF – Mean Time Between Failures), зрелость/полнота <информации> (Maturity). Отчетность по этим индикаторам может @@ -285,7 +285,7 @@ Progress) и индикаторы качества – ![Рисунок 3. Характеристики SCM-инструментов и связанные процедуры. [SWEBOK, 2004, с.7-4, рис. 3]](images/configuration_management_3-tools_and_processes.jpg) В этом примере система управления кодом поддерживает программные библиотеки -контролируя доступ к элементам библиотек, координирует действия множества +контролируя доступ к элементам библиотек, координирует действия множества пользователей и помогает в проведении рабочих процедур. Другие инструменты поддерживают процесс сборки и выпуска программного обеспечения и документации на основе программных элементов, содержащихся в библиотеках. Инструменты для @@ -646,7 +646,7 @@ SCM, необходимый для данной биб Первый шаг по управлению изменениями контролируемых элементов состоит в определении того, какие именно изменения надо производить. Процесс обработки запросов на изменения (software change request process), представленный на -рисунке 5, включает формальные процедуры по предложению (submitting) и записи +рисунке 5, включает формальные процедуры по предложению (submitting) и записи (recording) запросов на изменения, оценки потенциальной стоимости и влияния предлагаемых изменений, а также принятию, модификации или отказу от внесенных предложений по изменениям. Запросы на изменения элементов программных @@ -776,7 +776,7 @@ environment). Эти инструменты могут работ <программной инженерии>, как и спецификации, созданные в процессе разработки, могут содержать условия, которые не могут быть удовлетворены в заданной точке жизненного цикла. Отклонение (deviation) - утверждение -изменений, внесенных относительно предварительно сформулированных условий к +изменений, внесенных относительно предварительно сформулированных условий к разработке тех или иных аспектов разработки заданных элементов. Отказ (waiver) – утверждение дальнейшего использования элемента, которое отличается в той или иной степени от предварительно заданных условий. В обоих случаях используются @@ -875,7 +875,7 @@ milestones). Существует два достат критически-важного программного обеспечения): функциональный аудит конфигураций (Functional Configuration Audit, FCA) и физический аудит конфигураций (Physical Configuration Audit, PCA). Успешное (в терминах соответствия результатов -заданным условиям) завершение этих аудитов может быть обязательным требованиям +заданным условиям) завершение этих аудитов может быть обязательным требованиям для фиксирования базовой линии продукта. В то же время, если сравнивать контекст FCA и PCA для программного и аппаратного обеспечения, перед их выполнением необходимо четко оценивать реальные потребности в таких видах @@ -916,7 +916,7 @@ Configuration Audit, PCA). Успешное (в тер различные версии для разных платформ или редакции с различным набором функциональных возможностей), часто бывает необходимо создавать специализированные версии и пакеты (сборки) соответствующих материалов -(элементов, активов) для выпуска в качестве <самостоятельной> версии. +(элементов, активов) для выпуска в качестве <самостоятельной> версии. Программная библиотека (предоставляющая соответствующий инструментарий для такой сборки) играет ключевую роль в выполнении таких работ. @@ -996,7 +996,7 @@ Configuration Audit, PCA). Успешное (в тер Для поддержки таких функций управления выпуском могут требоваться соответствующие возможности инструментария поддержки (средств поддержки или “вспомогательных средств”, если, например, попытаться максимально приблизиться -к русскоязычной терминологии ГОСТ 12207). Также полезна и связь с +к русскоязычной терминологии ГОСТ 12207). Также полезна и связь с инструментальными возможностями поддержки процесса обработки запросов на изменения для отображения содержимого релиза на полученные запросы на изменения (SCR - software change request, включая сообщения об обнаруженных ранее и blob - 3ee2cd12d511378445c09aaccc36d928f4ff3f1c blob + 000adcbe06357fbc4c9a75e144a68501989a038f --- 7_software_engineering_management.md +++ 7_software_engineering_management.md @@ -434,7 +434,7 @@ structure). Это влияет на высокоур Крайне необходимо выделить как самостоятельную тему данной секции вопросы управления персоналом – people management, уделив особое внимание аспектам -экспертизы (не стоит путать с ролями/обязанностями) и лидерства специалистов в +экспертизы (не стоит путать с ролями/обязанностями) и лидерства специалистов в проектной команде. К этой же теме, также стоит отнести вопросы обучения, прохождения тренингов специалистами проектной команды. Наконец, к теме ресурсов имеет непосредственное отношение и определение необходимости и объема @@ -536,7 +536,7 @@ Measurement Process). ### Процесс мониторинга (Monitor Process) Соблюдение плана проверяется постоянно и через предопределенные интервалы -времени. Анализируются выходы (outputs) и условия завершения <задач>. +времени. Анализируются выходы (outputs) и условия завершения <задач>. Получаемые <в процессе измерений> результаты оцениваются в терминах требуемых характеристик (например, через процедуры обзора/оценки и аудита – review, audit). Затраты усилий (efforts), соблюдения расписания, стоимость к данному @@ -694,7 +694,7 @@ Process (2002 г.), основывающемся на необходимые для реализации процесса ведения измерений, а также включающий информационную модель измерений. -* “действия/работы” - activities, “задачи” – tasks: термин “задача” +* “действия/работы” - activities, “задачи” – tasks: термин “задача” используется для более глубокого уровня детализации, чем “действия/работы”; термины “действия” и “работы”, как вы уже заметили, часто используются взаимозаменяемым образом. Так или иначе, это вопрос договоренности о @@ -712,7 +712,7 @@ Process (2002 г.), основывающемся на должны быть оценены количественно, с тем, чтобы проект могу быть управляем в процессе достижения заданного результата. Для этого необходимо: - - Определить содержание измерений. Необходимость принять, в каких масштабах – + - Определить содержание измерений. Необходимость принять, в каких масштабах – на уровне какой организационной единицы* будут проводиться измерения – только в одной функциональной области, в рамках проекта, на уровне комплекса проектов или в организации, в целом. Все последующие задачи по ведению измерений, @@ -764,7 +764,7 @@ Process (2002 г.), основывающемся на приоритетов информационных потребностей и других критериев – таких, как стоимость сбора данных, возможность срыва процессных работ при сборе данных (например, в силу недостатка ресурсов), легкость анализа, легкость получения -точных и целостных данных и т.п. (см. стандарт 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 @@ -100,7 +100,7 @@ Process”). другие специализированные организационные структуры и органы, в общем случае называемые steering committee – “управляющий комитет”, обладающий наблюдательными функциями в отношении усилий, направленных на мониторинг, -контроль и выработку рекомендаций по поддержке и улучшению процесса +контроль и выработку рекомендаций по поддержке и улучшению процесса программной инженерии. На основе таких функций будем в дальнейшем использовать термин “наблюдательный орган”, подчеркивая реальные задачи такой комиссии и возможность как формальной, так и неформальной его организации. @@ -143,7 +143,7 @@ SEPG создается в рамках проекта Основной задачей EF является институализация (внедрение в повседневную практику) коллективного опыта и полученных уроков в масштабах организации на основе разработки, обновления и внедрения в проектную организацию “пакетов -опыта” – experience packages (например, руководств, моделей, курсов обучения и +опыта” – experience packages (например, руководств, моделей, курсов обучения и т.п.), <типовых> “активов процесса” – process assets. Проектная организация предлагает на рассмотрение EF свои продукты, планы, использовавшиеся при разработке, а также данные, собранные в процессе разработки и эксплуатации. @@ -165,7 +165,7 @@ SEPG проводит пилотное внедрен ### Цикл управления программным процессом (Software Process Management Cycle) Управление процессами в области программного обеспечения состоит из четырех -действий, представленных в рамках итеративного цикла. Это позволяет получать и +действий, представленных в рамках итеративного цикла. Это позволяет получать и анализировать отклики на постоянной основе и, <более оперативно> совершенствовать процесс. Вот эти четыре действия, предлагаемые SWEBOK: @@ -274,7 +274,7 @@ SWEBOK также отмечает роль “аге детального определения, но концентрируется на ключевых работах и их взаимосвязях. Примерами таких моделей[^8_1] являются водопадная (каскадная - waterfall), модель прототипирования, эволюционной разработки, -инкрементальная/итеративная, спиральная и т.п. Существуют различные сравнения +инкрементальная/итеративная, спиральная и т.п. Существуют различные сравнения и критерии выбора моделей, ссылки на некоторые из которых, в частности, даны в оригинальной версии SWEBOK. @@ -806,5 +806,5 @@ Software Process (TSP), направленный на В определенной степени, CMMI (и аналогичные модели в области управления проектами, например, PMI OPM3 и менеджмента качества, например, Six Sigma) -предоставляют обоснованный и подтвержденный базис для использования эталонной +предоставляют обоснованный и подтвержденный базис для использования эталонной техники. blob - 721310bd30d4909e5fb51c6d4aa561a90290eb19 blob + e311e627c1976f443babe458b440e4f91c5d2a8e --- 9_software_engineering_tools_and_methods.md +++ 9_software_engineering_tools_and_methods.md @@ -223,7 +223,7 @@ Amazon и др.), которые включают на тестирования и др., соответствующие, различным целям тестирования, представленным в секции 2.2 области знаний SWEBOK “Тестирование”, и естественно задающим “подвиды” возможного класса “специализированных или целевых -инструментов тестирования”, к которым, в частности, относится тестирование +инструментов тестирования”, к которым, в частности, относится тестирование производительности. ### Инструменты сопровождения (Software Maintenance Tools) @@ -342,7 +342,7 @@ SWEBOK идентифицированы три кат ## Методы программной инженерии (Software Engineering Methods) -Данная секция (подобласть) разделена на три темы: эвристические методы +Данная секция (подобласть) разделена на три темы: эвристические методы (heuristic methods), касающиеся неформализованных подходов; формальные методы (formal methods), обоснованные математически; методы прототипирования (prototyping methods), базирующиеся на различных формах прототипирования. Эти blob - ca52057605bb170091b6e1bfa7851f6f05ec90eb blob + bba382687a04421fd3bed7043660c325497e2cfe --- bibliography.md +++ bibliography.md @@ -64,7 +64,7 @@ Extreme Programming, 2002; перевод и изда - [Арчибальд, 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] – Рассел Д. Арчибальд. Искусство управления проектами: состояние и перспективы. Возможности и уровень зрелости организации в @@ -74,12 +74,12 @@ Wiley & Sons, Inc. (ISBN 0-471-26557-8) 1976 – Russe программные системы. 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 @@ -302,7 +302,7 @@ Processes” – “Процессы жизненно Стандарт отмечает, что работы проводятся с использованием проектного подхода и могут пересекаться по времени, т.е. проводиться одновременно или с наложением, -а также могут предполагать рекурсию и разбиение на итерации. +а также могут предполагать рекурсию и разбиение на итерации. #### Эксплуатация (5.4) @@ -330,7 +330,7 @@ Processes” – “Процессы жизненно Важно понимать, что стандарт 12207 не определяет последовательность и разбиение выполнения процессов во времени, адресуя этот вопрос также работам по адаптации стандарта к конкретным условиям и окружению и применению выбранных моделей, -практик, техник и т.п. +практик, техник и т.п. ### Адаптация стандарта @@ -356,7 +356,7 @@ Processes” – “Процессы жизненно * Необходимо отметить, что существует еще один стандарт жизненного цикла - ISO/IEC 15288 (выпущен в 2002 году), фокусирующийся на вопросах организации процессов жизненного цикла системного уровня (Life Cycle Processes – System) и -включающий специальный процесс - “Tailoring”, т.е. настройку, адаптацию +включающий специальный процесс - “Tailoring”, т.е. настройку, адаптацию жизненного цикла к конкретным требованиям и ограничениям, существующим или принятым в конкретной организации/подразделении или для заданного проекта.