 |
Стандарты в конструировании
|
|
|
|
Как известно, все существующие стандарты делятся на следующие классы.
1) Государственные (ГОСТ);
2) Отраслевые (ОСТ);
3) Стандарты предприятий (СТП);
4) Стандарты проектов.
Первые регламентируют основополагающие вопросы программирования, языков и программной документации. Примером является группа стандартов ГОСТ «Единая система программной документации» (ЕСПД), которая претерпела мало изменений с момента ее создания, пережила несколько поколений ЭВМ и революционных изменений технологий разработки программ. Другой пример - ГОСТ 28397-89. Языки программирования. Термины и определения.
Общепризнанной в мире ведущей организацией по разработке стандартов в области программирования является институт ANSI (Американский национальный институт стандартов). Он является лидером по созданию стандартов языков программирования, кодовых таблиц клавиш и символов, выводимых на экран, и еще многих других. Кроме того, в программировании широко используются общие стандарты ISO.
Стандарты создаются разными источниками, например, консорциумом OMG – Object Management Group (в частности, стандарты CORBA, UML, MDA, …), международными организациями по стандартизации, такими как ISO/IEC, IEEE, TMF, …, производителями платформ, операционных сред и т.д. (например, Microsoft, Sun Microsystems, CISCO, NOKIA, …), производителями инструментов, систем управления базами данных и т.п. (Borland, IBM, Microsoft, Sun, Oracle,...).
Кроме стандартов де-юре имеются стандарты де-факто. Последние устанавливаются ведущими фирмами-разработчиками программ и вычислительной техники. Стандарты де-факто появляются на основе некоторой широко известной разработки. Обычно такие стандарты определяют операционные системы, трансляторы с языков программирования, организацию файлов и средний уровень качества, достигаемый по окончании тестирования программ. Стандартизация обеспечивает возможность использования программной системы в любой среде. Примером являются стандарты операционных систем UNIX и Linux, языка Си и др.
|
|
|
Так, стандарт языка Си, в основном, регламентирует правила оформления кода и охватывает следующие соглашения.
1) Об именах переменных, классов и методов;
2) О структуре кода (отступах, расстановке скобок, количестве операторов и объявлении переменных в строке и т.д.);
3) О комментариях;
4) Об объявлении типов переменных, массивов и других структур и т.д.
Отраслевые стандарты, а также стандарты предприятий и проектов обычно регламентируют оформление кода конкретной программы и ее документации.
Стандарты, которые применяются при конструировании, включают в себя следующие составляющие:
· коммуникационные методы (например, стандарты форматов документов и оформления содержания);
· языки программирования и соответствующие стили кодирования (например, Java Language Specification, являющийся частью стандартной документации JDK – Java Development Kit и Java Style Guide, предлагающий общий стиль кодирования для языка Java);
· платформы (например, стандарты программных интерфейсов для вызовов функций операционной среды, такие как прикладные программные интерфейсы платформы Windows — Win 32 API, Application Programming Interface или.NET Framework SDK);
· инструменты (не в терминах сред разработки, но возможных средств конструирования – например, UML как один из стандартов для определения нотаций для диаграмм, представляющих структура кода и его элементов или некоторых аспектов поведения кода).
Определенные стандарты, соглашения и процедуры могут быть также созданы внутри организации или даже проектной команды. Они представляют собой соглашения о терминах, процедурах и других особенностях процессов конструирования. Наиболее распространенным является стандарт оформления кода.
|
|
|
Стандарт оформления кода (стандарт кодирования, стиль программиирования) (англ. coding standards, coding convention или programming style) — набор правил и соглашений, используемых при написании исходного кода на некотором языке программирования. Наличие общего стиля программирования облегчает понимание и поддержание исходного кода, написанного группой разработчиков, а также упрощает взаимодействие нескольких человек при разработке программного обеспечения.
Стандарт оформления кода обычно принимается и используется для единообразного оформления совместно используемого кода. Его целью является упрощение восприятия программного кода человеком, минимизация нагрузки на память и зрение при чтении программы.
Образцом для стандарта кодирования может стать набор соглашений, принятых в некоторой распространенной печатной работе по языку (например, уже рассмотренный стандарт кодирования на языке Си K&R, происходит из классического описания Си его авторами — Керниганом и Ричи), широко применяемая библиотека или API (так, на распространение венгерской нотации явно повлияло ее использование в MS-DOS и Windows API, а большинство стандартов кодирования для Delphi используют, в той или иной мере, манеру кодирования библиотеки VCL). Реже разработчик языка выпускает подробные рекомендации по кодированию. Например, выпущены стандарты кодирования на C# от Microsoft и на Java от Sun. Предложенная разработчиком или принятая в общеизвестных источниках манера кодирования в большей или меньшей степени дополняется и уточняется в корпоративных стандартах.
Стандарт сильно зависит от используемого языка программирования. Например, стандарт оформления кода для языка Си сильно отличается от стандарта для BASIC. Обычно стандарт имеет целью добиться такого положения, когда программист достаточной квалификации мог бы дать заключение о функции, выполняемой конкретным участком кода, а в идеале — также определить его корректность, изучив только сам этот участок кода и минимально изучив другие части программы. Иными словами, смысл кода должен быть виден из самого кода, без необходимости изучать контекст. Поэтому стандарт кодирования строится так, чтобы за счет определенного визуального оформления элементов программы повысить информативность кода для человека.
|
|
|
Обычно, стандарт оформления кода описывает:
a) способы выбора названий и используемый регистр символов для имен переменных и других идентификаторов:
· запись типа переменной в ее идентификаторе (венгерская нотация) и регистр символов (нижний, верхний и т.д.), использование знаков подчёркивания для разделения слов;
b) стиль отступов при оформлении логических блоков;
c) способ расстановки скобок, ограничивающих логические блоки;
d) использование пробелов при оформлении логических и арифметических выражений;
e) стиль комментариев и использование документирующих комментариев.
Вне стандарта подразумевается:
· отсутствие магических чисел (числовых констант);
· ограничение размера кода по горизонтали (чтобы помещался на экране) и вертикали (чтобы весь код файла держался в памяти), а также функции или метода - на один экран.
Основные принципы распространенных стандартов кодирования в последнее время оказывают влияние на синтаксис вновь создаваемых языков программирования. В некоторых из них соглашения, которые раньше применялись только в стандартах кодирования, стали обязательными элементами синтаксиса. В результате, если раньше недисциплинированный программист мог игнорировать стандарты кодирования из личных соображений, ради удобства или скорости написания кода, то теперь, при работе на новых языках, соблюдение стандартов часто контролируется транслятором.
2. Управление конструированием
2.1 Модели конструирования
Технология конструирования программного обеспечения – это система инженерных принципов разработки ПО, которое имеет требуемое качество. Различают методы, средства и процедуры этой технологии.
Методы обеспечивают решение следующих задач:
a) Планирование и оценка проекта;
b) Анализ системных и программных требований;
c) Проектирование структур данных, алгоритмов и программных структур;
|
|
|
d) Кодирование;
e) Тестирование;
f) Сопровождение.
Средства (утилиты) обеспечивают автоматизированную или автоматическую поддержку методов. Они могут объединяться в системы автоматизированного конструирования ПО. Такие системы называют CASE-системами (Computer Aided Software Engineering).
Процедуры объединяют методы и средства и обеспечивают непрерывную последовательность разработки. Они определяют:
a) Порядок применения методов и утилит;
b) Формирование отчетов;
c) Порядок контроля обеспечения качества и координации изменений;
d) Формирование этапов выполнения работ.
Процесс конструирования программного обеспечения состоит из последовательности шагов, использующих различные методы, процедуры и утилиты. Эти последовательности называют парадигмами технологии конструирования программного обеспечения. Они связаны с моделями жизненного цикла программ.
Общеизвестно, что наиболее распространенными парадигмами и моделями жизненного цикла являются:
1) Каскадная или водопадная;
2) Инкрементная;
3) V-образная;
4) Эволюционная (спиральная);
5) Компонентно-ориентированная.
Они подробно изучались в рамках дисциплины «Управление проектами». Здесь мы их рассмотрим кратко.
Каскадная модель является классической моделью жизненного цикла. Она представляет процесс разработки ПО в виде последовательности этапов, представленных на рис. 17. Эта модель применяется к системам, требования к которым полностью определены.
Рис. 17. Каскадная модель жизненного цикла ПО
Достоинствами каскадной модели являются упорядоченный процесс конструирования с четким планом и графиком следования этапов.
Недостатки:
a) Требования к проекту на начальном этапе, как правило, определены частично, поэтому в дальнейшем возможны их уточнения и изменения;
b) Этапы выполняются последовательно, поэтому результаты разработки заказчик получает в самом конце.
Инкрементная модель объединяет достоинства каскадной и методов макетирования. При этом в начале определяются все пользовательские и системные требования. Затем разрабатывается последовательность версий. Каждая версия реализует часть возможностей системы, как показано на рис. 18. Причем, на каждом инкременте получают работающий продукт.
Эта модель применяется в технологии экстремального программирования, которая будет рассмотрена позднее.
V-образная или V-модель отображает связь процессов разработки и тестирования программного обеспечения. Она представлена на рис. 19. В модели основные этапы жизненного цикла программного обеспечения образуют левую сторону «V»,причем кодирование находится в самой нижней точке диаграммы, а тестирование образует ее правую сторону. Для наглядности на диаграмме показаны на все этапы разработки ПО. Причем, V-модель может быть наложена на итеративную или спиральную модели.
|
|
|
Рис. 18. Инкрементная модель
Рис. 19. V-образная модель
Основным достоинством V-модели является связь разработки программ с их тестированием, валидацией и верификацией программного обеспечения.
Валидация (Validation) - это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя и требованиям к системе.
Верификация (Verification) - это процесс оценки системы или ее компонентов с целью определения удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа, т.е. выполняются ли цели, сроки, задачи по разработке проекта, определенные в начале текущей фазы.
Спиральная модель представляет собой классический пример эволюционной стратегии конструирования. Она использует дополнительный важный элемент - анализ рисков. В ней отображаются четыре основных стадии разработки программного обеспечения (см. рис. 20).
1 – начальный сбор требований и планирование проекта; 2 – та же работа на основе рекомендаций заказчика; 3 – анализ риска на основе начальных требований; 4 - анализ риска на основе рекомендаций заказчика; 5 – переход к комплексной системе; 6 – начальный макет системы; 7 – следующий уровень макета; 8 – сконструированная система; 9 – оценивание заказчиком.
Рис. 20. Спиральная модель
1. Планирование – определение целей, вариантов и ограничений.
2. Анализ риска – анализ вариантов и распознавание и выбор риска.
3. Конструирование – разработка продукта следующего уровня.
4. Оценивание заказчиком результатов.
Достоинства спиральной модели:
1) Более точно отображает процесс разработки ПО;
2) Позволяет учитывать риск разработки;
3) Использует моделирование для оценки характеристик.
Недостатки этой модели:
1) Повышенные требования к заказчику;
2) Сложность контроля и управления временем разработки.
Компонентно-ориентированная модель основана на эволюционной стратегии конструирования и является развитием спиральной. В ней конкретизирован квадрант конструирования (см. рис. 21). При этом учитывается, что новая разработка предполагает повторное использование существующих компонентов.
Рис. 21. Компонентно-ориентированная модель
Программные компоненты из предыдущих проектов хранятся в библиотеке. Они могут быть включены в новый проект, т.е использованы повторно. Если таких компонентов нет, то они разрабатываются и затем включаются в библиотеку. Повторное использование будет рассмотрено позднее.
Достоинства компонентно-ориентированной модели:
a) Уменьшение времени разработки в среднем на 30%;
b) Сокращение стоимости разработки в среднем на 70%;
c) Увеличение производительности труда в среднем в 1.5 раза.
Планирование конструирования
Планирование конструкторской деятельности определяет порядок, в котором создаются компоненты, проводятся работы по обеспечению качества получаемого программного обеспечения, распределяются задачи и соответствующие ресурсы, в том числе, определяются назначения работ конкретным инженерам-программистам, членам проектной группы. Все это происходит в соответствии с правилами, используемым методом проектирования и моделью жизненного цикла.
При планировании программного проекта необходимо оценить:
· людские ресурсы (в человеко-месяцах);
· продолжительность (в календарных датах);
· стоимость.
При этом обычно исходят из прошлого опыта. Если новый проект по размеру и функциям похож на предыдущий проект, потребуются примерно такие же ресурсы, время и деньги.
При планировании выполняются следующие этапы:
1) определяется набор проектных задач;
2) устанавливаются связи между задачами;
3) оценивается сложность каждой задачи;
4) определяются людские и другие ресурсы;
5) создается сетевой график и проводится его временная разметка.
Планирование заключается в определении порядка разработки компонентов и методов обеспечения качества. Измерение в конструировании, о котором будет разговор позднее, ориентировано на количественную оценку объема кода, использования стандартных или библиотечных компонент, вероятности появления дефектов и количественных показателей качества ПО.
Управление инженерией ПО (менеджмент) – это руководство работой команды разработчиков ПО в процессе выполнения плана, определение критериев и оценка процессов и результатов проекта с использованием общих методов управления, планирования и контроля работ.
Как любое управление, менеджмент ПО предполагает планирование, координацию, измерение, контроль и отчет по процессу управления проектом. Координацию людских, финансовых и технических ресурсов выполняет менеджер проекта, аналогично тому, как это делается в любых технических проектах. В его обязанности входит соблюдение запланированных бюджетных и временных характеристик и ограничений, стандартов и сформулированных требований. Общие вопросы управления проектом регламентируются стандартом ISO/IEC 12207 – Software life cycle processes, в котором управление проектом рассматривается как дополнительный организационный процесс ЖЦ,
Управление инженерией ПО (Software Engineering Management) предусматривает реализацию следующих процессов:
a) организационного управления (Organizational Management),
b) управления процессом и проектом (Process/Project Management),
c) измерения инженерии ПО (Software Engineering Measurement).
Организационное управление – это планирование и составление графика работ, оценка их стоимости, подбор и управление персоналом, контроль за выполнением работ согласно принятым стандартам и планам. Его главными задачами являются:
·управление персоналом (обучение, мотивация и др.),
·коммуникации между сотрудниками и средой (сценарии, встречи, презентации и др.),
·риски (минимизация риска, техники определения риска, выбор решений по их предотвращению и др.).
При управлении проектом создается такая структура коллектива, специалисты которой могут выполнить проект. Они распределяются по работам и все вместе реализуют задачи проекта под руководством менеджера. Проекту выделяется оборудование, средства и исполнители. Проводится распределение обязанностей специалистов и их выполнение с учетом заданной стоимости и срока разработки.
Управление процессом включает в себя:
· составление плана проекта, построение графиков работ (сетевых или временных диаграмм) исходя из имеющихся ресурсов, а также
· распределение персонала по работам с учетом сроков и стоимости их выполнения и др.;
· анализ финансовой, технической, операционной и социальной политики организации для выбора правильной стратегии выполнения плана;
· контроль процесса управления планами и продуктами.
Управление проектом заключается в уточнении требований и проверке (валидации) их на соответствие, в просмотре и ревизии требований на соответствие заданным спецификациям качества, а также в проверке (верификации) правильности реализованных функций в отдельных продуктах проекта. Он учитывает сроки выполнения работ, их начала и окончания. Результаты планирования отображаются в сетевых диаграммах (PERT – Program Evaluation and Review Technique, CРM – Сritical Path Method и др.), предназначенных для отображения полного комплекса работ, времени их выполнения и зависимостей между разными работами.
Наиболее распространенной является сетевая диаграмма PERT. Она представляет собой граф, в вершинах которого располагаются работы, а дуги задают связи между ними. Другой тип сетевой диаграммы - событийная. Ее вершины являются событиями, а работы задаются линиями между двумя узлами–событиями. Ожидаемое время выполнения работы для сетевых диаграмм оценивается с помощью среднего весового значения трех оценок: оптимистической, пессимистической и ожидаемой – вероятностной. Эти оценки берутся из заданного времени на разработку и заключений экспертов, оценивающих отдельные работы и в комплексе.
После составления плана решается вопрос об управлении и контроле его выполнения. Процесс контроля обычно направлен на внесение изменений в проект, оценку риска и принимаемых решений.
Управление рисками является важной проблемой выполнения проекта и представляет собой процесс определения рисков и разработки мероприятий по уменьшению их влияния на ход выполнения проекта.
Риск – вероятность проявления неблагоприятных обстоятельств, которые могут повлиять на реализацию проекта, его качество и на управление разработкой (например, увольнение сотрудника и отсутствие замены для продолжения работ и др.). При управлении рисками проводится идентификация и его анализ, а также оценка критических рисков и планирование непредвиденных ситуаций, касающихся рисков. Предотвращение риска заключается в выполнении действий, которые его снимают (например, увеличение времени разработки и др.), уменьшают вероятность появления нового риска при реорганизации проекта, БД или транзакций, а также при выполнении ПО.
|
|
|
