Итеративная

Итеративный подход (англ. iteration — повторение) — выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы. Проект при этом подходе в каждой фазе развития проходит повторяющийся цикл: Планирование — Реализация — Проверка — Оценка (англ. plan-do-check-act cycle).

Преимущества итеративного подхода:

• снижение воздействия серьезных рисков на ранних стадиях проекта, что ведет к минимизации затрат на их устранение;

• организация эффективной обратной связи проектной команды с потребителем (а также заказчиками, стейкхолдерами) и создание продукта, реально отвечающего его потребностям;

• акцент усилий на наиболее важные и критичные направления проекта;

• непрерывное итеративное тестирование, позволяющее оценить успешность всего проекта в целом;

• раннее обнаружение конфликтов между требованиями, моделями и реализацией проекта;

• более равномерная загрузка участников проекта;

• эффективное использование накопленного опыта;

• реальная оценка текущего состояния проекта и, как следствие, большая уверенность заказчиков и непосредственных участников в его успешном завершении.

Примеры итеративных методологий –

• Пошаговая разработка

• Спиральная одель

• RUP rational unified process

RUP

В основе RUP лежат следующие принципы:

• Ранняя идентификация и непрерывное (до окончания проекта) устранение основных рисков.

• Концентрация на выполнении требований заказчиков к исполняемой программе (анализ и построение модели прецедентов (вариантов использования)).

• Ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки.

• Компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта.

• Постоянное обеспечение качества на всех этапах разработки проекта (продукта).

• Работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам.

Фазы :

• начало,

• уточнение,

• построение (Фаза Построение завершается первым внешним релизом системы и вехой начальной функциональной готовности),

• внедрение ( создается финальная версия продукта и передается от разработчика к заказчику).

Спиральная модель,

предложенная Барри Боэмом в 1988 году, стала существенным прорывом в понимании природы разработки ПО. Она представляет собой процесс разработки программного обеспечения, сочетающий в себе как проектирование, так и постадийное прототипирование с целью сочетания преимуществ восходящей и нисходящей концепции, делающая упор на начальные этапы жизненного цикла: анализ и проектирование. Отличительной особенностью этой модели является специальное внимание рискам, влияющим на организацию жизненного цикла. Боэм формулирует десять наиболее распространённых (по приоритетам) рисков:

1. Дефицит специалистов.

2. Нереалистичные сроки и бюджет.

3. Реализация несоответствующей функциональности.

4. Разработка неправильного пользовательского интерфейса.

5. «Золотая сервировка», перфекционизм, ненужная оптимизация и оттачивание деталей.

6. Непрекращающийся поток изменений.

7. Нехватка информации о внешних компонентах, определяющих окружение системы или вовлечённых в интеграцию.

8. Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.

9. Недостаточная производительность получаемой системы.

10. «Разрыв» в квалификации специалистов разных областей знаний.

Каждый виток спирали соответствует созданию фрагмента или версии программного обеспечения, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации. Каждый виток разбит на 4 сектора:

• оценка и разрешение рисков,

• определение целей,

• разработка и тестирование,

• планирование.

На каждом витке спирали могут применяться разные модели процесса разработки ПО. В конечном итоге на выходе получается готовый продукт. Модель сочетает в себе возможности модели прототипирования и водопадной модели. Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная задача — как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований. Основная проблема спирального цикла — определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков. 

Scrum

— методология управления развитием информационных систем для гибкой разработки программного обеспечения. Scrum чётко делает акцент на качественном контроле процесса разработки.

это набор принципов, на которых строится процесс разработки, позволяющий в жёстко фиксированные небольшие промежутки времени (спринты от 2 до 4 недель) предоставлять конечному пользователю работающее ПО с новыми возможностями, для которых определён наибольший приоритет.

По методике Scrum в производственном процессе есть определенные роли, разбитые на 2 группы «свиней» и «цыплят». Эти названия были использованы из-за шутки. .. Так что свиньи создают продукт, тогда как цыплята заинтересованы, но не настолько — ведь им всё равно, будет ли проект удачным или нет, на них это мало отразится. Требования, пожелания, идеи и влияние цыплят принимаются во внимание, но им не разрешают непосредственно включаться в ход Scrum-проекта.

Артефакты

Product backlog (бэклог)— это документ, содержащий список требований к функциональности, которые упорядочены по степени важности. Product backlog представляет собой список того, что должно быть реализовано. Элементы этого списка называются «историями» (user story) или элементами backlog’a (backlog items). Product backlog открыт для редактирования для всех участников Scrum-процесса.

Sprint Backlog — содержит функциональность, выбранную Product Owner из Product Backlog. Все функции разбиты по задачам, каждая из которых оценивается командой. Каждый день команда оценивает объем работы, который нужно проделать для завершения задач.

Burndown chart — показывает, сколько уже исполнено и сколько ещё остаётся сделать.

Planning Meeting - Планирование спринта происходит в начале итерации

Daily Scrum

Demo Meeting – демонстрация

Retrospective Meeting - Ретроспектива

13. Организация проектирования и разработки ПО []

Готовый ответ Тони

Экстремальное программирование (XP) – это упрощенная методология организации разработки программ для небольших и средних по размеру команд разработчиков, занимающихся созданием программного продукта в условиях неясных или быстро меняющихся требований.

Цели XP

Основными целями XP являются повышение доверия заказчика к программному продукту путем предоставления реальных доказательств успешности развития процесса разработки и резкое сокращение сроков разработки продукта. При этом XP сосредоточено на минимизации ошибок на ранних стадиях разработки. Это позволяет добиться максимальной скорости выпуска готового продукта и даёт возможность говорить о прогнозируемости работы. Практически все приемы XP направлены на повышение качества программного продукта.

Принципы XP

Основными принципами являются:

Итеративность. Разработка ведется короткими итерациями при наличии активной взаимосвязи с заказчиком. Итерации как таковые предлагается делать короткими, рекомендуемая длительность – 2-3 недели и не более 1 месяца. За одну итерацию группа программистов обязана реализовать несколько свойств системы, каждое из которых описывается в пользовательской истории. Пользовательские истории (ПИ) в данном случае являются начальной информацией, на основании которой создается модуль. Они отличаются от вариантов использования (ВИ). Описание ПИ короткое – 1-2 абзаца, тогда как ВИ обычно описываются достаточно подробно, с основным и альтернативными потоками, и дополняются моделью. ПИ пишутся самими пользователями, которые в XP являются частью команды, в отличие от ВИ, которые описывает системный аналитик. Отсутствие формализации описания входных данных проекта в XP стремятся компенсировать за счет активного включения в процесс разработки заказчика как полноправного члена команды.

Простота решений. Принимается первое простейшее рабочее решение. Экстремальность метода связана с высокой степенью риска решения, обусловленного поверхностностью анализа и жестким временным графиком. Реализуется минимальный набор главных функций системы на первой и каждой последующей итерации; функциональность расширяется на каждой итерации.

Интенсивная разработка малыми группами (не больше 10 человек) и парное программирование (когда два программиста вместе создают код на одном общем рабочем месте), активное общение в группе и между группами. Все это нацелено на как можно более раннее обнаружение проблем (как ошибок, так и срыва сроков). Парное программирование направлено на решение задачи стабилизации проекта. При применении XP методологии высок риск потери кода по причине ухода программиста, не выдержавшего интенсивного графика работы. В этом случае второй программист из пары играет роль «наследника» кода. Немаловажно и то, как именно распределены группы в рабочем пространстве – в XP используется открытое рабочее пространство, которое предполагает быстрый и свободный доступ всех ко всем.

Обратная связь с заказчиком, представитель которого фактически вовлечен в процесс разработки.

Достаточная степень смелости и желание идти на риск.

Приемы XP (практики)

Обычно XP характеризуют набором из 12 правил (практик), которые необходимо выполнять для достижения хорошего результата. Ни одна из практик не является принципиально новой, но в XP они собраны вместе.

Планирование процесса. Вся команда разработчиков собирается вместе, принимается коллективное решение о том, какие свойства системы будут реализованы в ближайшей итерации. Трудоемкость реализации каждого свойства определяется самими программистами.

Тесное взаимодействие с заказчиком. Представитель заказчика должен быть членом XP-команды. Он пишет ПИ, выбирает истории, которые будут реализованы в конкретной итерации, и отвечает на вопросы, касающиеся бизнеса. Представитель заказчика должен быть экспертом в автоматизируемой предметной области. Необходимо наличие постоянное обратной связи с представителем заказчика.

Общесистемные правила именования. Хорошие системные правила именования предполагаютпростоту именования классов и переменных. Команда разработчиков должна иметь единые правила именования.

Простая архитектура. Любое свойство системы должно быть реализовано как можно проще. Программисты в XP-команде работают под девизом: «Ничего лишнего!». Принимается первое простейшее работающее решение, реализуется необходимый уровень функциональности на данный момент. Тем самым экономится время программиста.

Рефакторинг. Это оптимизация существующего кода с целью его упрощения, Такая работа должна вестись постоянно. Сохраняя код прозрачным и определяя его элементы всего один раз, программисты сокращают число ошибок, которые впоследствии придется устранять. При реализации каждого нового свойства системы программист должен подумать над тем, можно ли упростить существующий код и как это поможет реализовать новое свойство. Кроме того, нельзя совмещать рефакторинг с дизайном: если создается новый код, рефакторинг следует отложить.

Парное программирование. Все программисты должны работать в парах: один пишет код, другой смотрит. Таким образом, необходимо размещать группу программистов в одном месте. XP наиболее успешно работает в нераспределенных коллективах программистов и пользователей.

40-часовая рабочая неделя. Программист не должен работать более 8 часов в день. Необходимость сверхурочной работы – это четкий индикатор проблемы на данном конкретном направлении разработки. Поиск причин сверхурочной работы и их скорейшее устранение – одно из основных правил.

Коллективное владение кодом. Каждый программист в коллективе должен иметь доступ к коду любой части системы и право вносить изменения в любой код. Обязательное правило: если программист внес изменения и система после этого работает некорректно, то именно этот программист должен исправить ошибки.

Единые стандарты кодирования. Стандарты кодирования нужны для обеспечения других практик: коллективного владения кодом, парного программирования и рефакторинга. Без единого стандарта выполнять эти практики как минимум сложнее, а в реальности вообще невозможно: группа будет работать в режиме постоянной нехватки времени. Команда работает над проектом продолжительное время. Люди приходят и уходят. Никто не кодирует в одиночку и код принадлежит всем. Всегда будут моменты, когда необходимо будет понять и скорректировать чужой код. Разработчики будут удалять дублирующий код, анализировать и улучшать чужие классы и т. п. Со временем нельзя будет сказать, кто автор конкретного класса. Следовательно, все должны подчиняться общим стандартам кодирования – форматирование кода, именование классов, переменных, констант, стиль комментариев. Вышесказанное означает, что все члены команды должны договориться об общих стандартах кодирования. Неважно каких, но все обязаны им подчиняются.

Небольшие релизы. Минимальная итерация – один день, максимальная – месяц; чем чаще осуществляются релизы, тем больше недостатков системы будет выявлено. Первые релизы помогают выявить недостатки на самых ранних стадиях, далее функциональность системы расширяется на основании ПИ. Поскольку пользователь включается в процесс разработки начиная с первого релиза, то он оценивает систему и выдает пользовательскую историю и замечания. На основании этого определяется следующая итерация, то есть, каким будет новый релиз. В XP все направлено на обеспечение непрерывной обратной связи с пользователями.

Непрерывная интеграция. Интеграция новых частей системы должна происходить как можно чаще, как минимум раз в несколько часов. Основное правило интеграции следующее: интеграцию можно производить, если все тесты проходят успешно. Если тесты не проходят, то программист должен либо внести исправления и тогда интегрировать составные части системы, либо вообще не интегрировать их. Правило это – жесткое и однозначное. Если в созданной части системы имеется хотя бы одна ошибка, то интеграцию производить нельзя. Частая интеграция позволяет быстрее получить готовую систему, вместо того чтобы тратить на сборку неделю.

Тестирование. В отличие от большинства остальных методологий тестирование в XP – одно из важнейших составляющих. Экстремальный подход предполагает, что тесты пишутся до написания кода. Каждый модуль обязан иметь unit test – тест данного модуля. Таким образом, в XP осуществляется регрессионное тестирование, «неухудшение качества» при добавлении функциональности. Большинство ошибок исправляются на стадии кодирования. Тесты пишут сами программисты, любой из них имеет право написать тест для любого модуля. Еще один важный принцип: тест определяет код, а не наоборот (test-driven development), то есть кусок кода кладется в хранилище тогда и только тогда, когда все тесты прошли успешно, в противном случае данное изменение кода отвергается.

Процесс XP является неформальным, но требует высокого уровня самодисциплины. Если это правило не выполняется, то XP мгновенно превращается в хаотичный и неконтролируемый процесс. XP не требует от программистов написания множества отчетов и построения массы моделей. В XP каждый программист считается квалифицированным работником, который профессионально и с большой ответственностью относится к своим обязанностям. Если в команде этого нет, то внедрять XP абсолютно бессмысленно – лучше для начала заняться перестройкой команды. Риск разработки снижается только в команде, которой XP подходит идеально, во всех остальных случаях XP – это процесс разработки с наиболее высокой степенью риска, поскольку другие методы снижения коммерческих рисков, кроме человеческого фактора, в XP просто отсутствуют.

Граничные условия.

- коммуникация большого количества команд (по 6-10 человек)

- живут по схеме times-material, а не по четкому плану

- проверяемые требования

- высокий уровень программ

- четкая поддержка со стороны менеджера

14. Организация проектирования и разработки ПО []

Готовый ответ Вали

Назначение процесса планирования ПО состоит в том, чтобы определить методы создания такого ПО, которое позволить реализовать системные требования и обеспечить требуемый уровень качества.

Планирование позволяет:

• создавать планы информационных систем, поддерживающие бизнес-направление фирмы;

• ориентировать разработчиков на конечные бизнес-результаты, а не на окончание проектов информационных систем;

• эффективнее использовать ресурсы информационной системы;

• закладывать большую управляемость и лучшую интеграцию существующих и будущих систем;

• быть уверенным в том, что ИС будет соответствовать общему направлению развития организации;

• учесть мнение конечных пользователей;

• создавать условия для правильного реагирования на непредвиденные ситуации.

Принципы планирования Планирование осуществляется в соответствии с рядом принципов, т.е. правил, каковыми сегодня считаются: 1)                Необходимость 2)                Непрерывность 3)                Эластичность и гибкость 4)                Единство и полнота 5)                Экономичность 6)                Детализация и точность 7)                Оптимальность 8)                Связь уровней управления 9)                Участие Они определяют содержание и ориентацию плановой работы на всех стадиях проекта и на последующей реализации. Правильное соблюдение принципов планирования создает предпосылки эффективной работы и уменьшает риск отрицательных результатов.

2) НЕПРЕРЫВНОСТЬ – смысл непрерывности планирования заключается в том, что процесс планирования на предприятии должен осуществляться постоянно в рамках жизненных циклах проектов. 3) ГИБКОСТЬ – в понятии гибкости связано с непрерывностью планирования, в придании плану и процессу способность менять свою направленность в связи с возникшей ситуацией и непредсказуемыми обстоятельствами. Для осуществления данного принципа планы следует составлять так, чтобы в них можно было внести коррективу. Поэтому в планы обычно включают резервы. 4) ТОЧНОСТЬ – все планы должны быть составлены с наивысшей точностью, т.е. конкретизированные и детализированы в той степени, в которой позволят внутренние и внешние условия фирмы. 5) УЧАСТИЕ - он говорит о том, что каждый член организации становиться участником плановой деятельности, не зависимо от занимаемой должности и выполняемых функций.

Основные риски, учет рисков:

Риск 1: ошибки, присущие расписанию  

Описание: благодаря своей неощутимой  природе и уникальности программного обеспечения, процесс разработки ПО сложно оценить и расписать.

Решение: все больше вовлекайте команду в процесс планирования и оценки. Получите отзывы на ранней стадии и обсудите возможные ошибки и нестыковки лично с заказчиком.

Гибкий метод: в проектах, использующих гибкую методологию, команда активно вовлечена в планирование  и оценку посредством таких действий, как  экстремальное программирование (Extreme Programming, XP) и семинары Wideband Delphi. Работая в коротких этапах, скорость работы команды резко увеличивается, и это явно видно всем участникам проекта, кто  на данный момент более вовлечен в проект. Вкратце, настоящий прогресс сложно скрыть от владельцев.

Риск 2: появление новых требований

Описание: по ходу продвижения проекта появляются все новые требования, которые могут нарушить все сроки и оценки.

Решение: постоянное вовлечение клиентов и разработчиков.

Гибкий метод: в проектах, использующих гибкую методологию, регулярно планируются и обсуждаются все функции и сроки на границах каждого этапа. Изменения и требования в таких проектах принимаются как данность. Вместо простого использования методов подавления изменений, планируются сессии по установлению приоритетов, которые позволяют рационально выполнить все изменения. Невозможно протиснуть канат в игольное ушко, но вы уже осведомлены о существовании данной проблемы и у вас есть метод работы с изменениями, который можно использовать на ранних стадиях.

Риск 3: смена сотрудников

Описание: ключевые сотрудники могут покинуть проект, унося при этом с собой критическую информацию, что значительно откладывает и сносит проект с рельсов.

Решение: высокий уровень сотрудничества и обмена информацией в команде.

Гибкий метод: техники обмена информацией в случае с гибкой методологией, такие как парное программирование, использование обобщенного кода и частые отчеты, каждодневно противостоят вероятности потери информации. При снижении фактора утери сотрудника многие члены команды обмениваются ключевой информацией, следовательно, риск, связанный с уходом ключевых сотрудников, низок. Также стоит учесть, что, работая в захватывающей, награждающей и кооперирующей среде, как в случае с проектами, основанными на гибкой методологии, люди реже хотят покидать проект.

Риск 4: декомпозиция спецификации

Описание: при старте процесса кодирования и интеграции становится ясно, что спецификация неполная и содержит конфликтные требования.

Решение : наймите преданного менеджера по продукции для осуществления критических договоров и решений.

Гибкий метод: проекты с гибкой методологией используют опытных пользователей, экспертов в области или посредника клиентов в качестве менеджера по продукции. Идея заключается в том, что кто-то (или некая группа) должен быть готов отвечать на вопросы и осуществлять решения в проектах. Традиционные проекты страдают от декомпозиции специификации, когда никто не исполняет такую роль, и появляются конфликтующие предположения и решения. Проекты должны обладать некой ролью владельца проекта в составе команды для обеспечения своевременного принятия решений.

Риск 5: низкая продуктивность

Описание: наличие впереди длительных сроков приводит к тому, что на ранних стадиях зачастую отсутствует  чувство срочности в работе, а это  в результате дает в начале проекта  потерю времени, которое уже нельзя вернуть .

Решение: короткие итерации, нужные люди в команде, лидерство и развитие команды.

Гибкий метод:гибкие методы осознают присутствие закона Паркинсона и синдром студента в проектах. Закон Паркинсона гласит о том, что работа удлиняется, заполняя доступные рамки времени, а синдром студента говорит о том, что имея срок, люди зачастую ничего не делают до того момента, как этот срок будет близок. Применяя короткие итерации, работа разделяется  на множество этапов (обычно 1-4 недели) и  всегда существует чувство срочности. Гибкая методология не концентрируется на нужном персонале и развитии команды, но это основа роли лидера и применяется как в гибкой, так и в

Процесс управления рисками состоит из превентивных решений и действий:

•выявления рисков;

•выявления рисков, требующих вмешательства;

•разработки стратегии снижения рисков.

Эффективная проектная группа оценивает риски в течение всего жизненного цикла проекта и использует эти оценки в процессе принятия решений на всех фазах проекта.

Ещё риски:

1. Дефицит специалистов.

2. Нереалистичные сроки и бюджет.

3. Реализация несоответствующей функциональности.

4. Разработка неправильного пользовательского интерфейса.

5. «Золотая сервировка», перфекционизм, ненужная оптимизация и оттачивание деталей.

6. Непрекращающийся поток изменений.

7. Нехватка информации о внешних компонентах, определяющих окружение системы или вовлечённых в интеграцию.

8. Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.

9. Недостаточная производительность получаемой системы.

10. «Разрыв» в квалификации специалистов разных областей знаний.

Планирование в различных методологиях :

SCRUM (гибкая методология)

Каждый этап разработки (спринт) имеет этап планирования. Возможности ПО к реализации в очередном спринте определяются в начале спринта на этапе планирования и не могут изменяться на всём его протяжении. Существует совет по планированию спринта. Product backlog представляет собой список того, что должно быть реализовано (определяется советом по планированию)

XP

В XP существует такая практика как игра в планирование. Игра в планирование

Основная цель игры в планирование — быстро сформировать приблизительный план работы и постоянно обновлять его по мере того, как условия задачи становятся все более четкими. Артефактами игры в планирование является набор бумажных карточек, на которых записаны пожелания заказчика (customer stories), и приблизительный план работы по выпуску следующих одной или нескольких небольших версий продукта. Критическим фактором, благодаря которому такой стиль планирования оказывается эффективным, является то, что в данном случае заказчик отвечает за принятие бизнес-решений, а команда разработчиков отвечает за принятие технических решений. Если не выполняется это правило, весь процесс распадается на части.

Спиральная модель

Каждый виток спирали соответствует созданию фрагмента или версии программного обеспечения, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спиралиСрок разработки ПО зависит от требований, предъявляемых к программному продукту

Типы планов : (см. ГОСТ 51904-2002 стр. 16 и далее):

План сертификации в части ПО

План разработки

План верификации

План квалификационного тестирования

План управления конфигурацией

План обеспечения качества

И .тд.

15. Организация проектирования и разработки ПО []

Готовый ответ Маши

Определение

Создание архитектуры по – это процесс формирования структурированного решения, отвечающего всем техническим и операционным требованиям и обеспечивающего оптимальные общие атрибуты качества, такие как производительность, безопасность и управляемость. Он включает принятие ряда решений на основании широкого диапазона факторов. Каждое из этих решений может иметь существенное влияние на качество, производительность, удобство обслуживания и общий успех по.

Основные принципы проектирования

Разделение функций. Разделите приложение на отдельные компоненты с, по возможности, минимальным перекрытием функциональности. Важным фактором является предельное уменьшение количества точек соприкосновения, что обеспечит высокую связность (high cohesion) и слабую связанность (low coupling). Неверное разграничение функциональности может привести к высокой связанности и сложностям взаимодействия, даже несмотря на слабое перекрытие функциональности отдельных компонентов.

 Принцип единственности ответственности. Каждый отдельно взятый компонент или модуль должен отвечать только за одно конкретное свойство/функцию или совокупность связанных функций.

 Принцип минимального знания (также известный как Закон Деметера (Law of Demeter, LoD)). Компоненту или объекту не должны быть известны внутренние детали других компонентов или объектов.

 Не повторяйтесь (Don’t repeat yourself, DRY). Намерение должно быть обозначено только один раз. В применении к проектированию приложения это означает, что определенная функциональность должна быть реализована только в одном компоненте и не должна дублироваться ни в одном другом компоненте.

 Минимизируйте проектирование наперед. Проектируйте только то, что необходимо. В некоторых случаях, когда стоимость разработки или издержки в случае неудачного дизайна очень высоки, может потребоваться полное предварительное проектирование и тестирование. В других случаях, особенно при гибкой разработке, можно избежать масштабного проектирования наперед (big design upfront, BDUF). Если требования к приложению четко не определены, или существует вероятность изменения дизайна со временем, старайтесь не тратить много сил на проектирование раньше времени. Этот принцип называют YAGNI («You ain’t gonna need it»1)

Основное назначение архитектуры – описание использования или взаимодействия основных элементов и компонентов приложения.

Цели архитектуры

Раскрывать структуру системы, но скрывать детали реализации.

• Реализовывать все варианты использования и сценарии.

• По возможности отвечать всем требованиям различных заинтересованных сторон.

• Выполнять требования, как по функциональности, так и по качеству.

Методология

Архитектурный стиль, иногда называемый архитектурным шаблоном – это набор принципов, высокоуровневая схема, обеспечивающая абстрактную инфраструктуру для семейства систем. Архитектурный стиль улучшает секционирование(разделение хранимых объектов баз данных (таких как таблиц, индексов, материализованных представлений) на отдельные части с раздельными параметрами физического хранения. Используется в целях повышения управляемости, производительности и доступности для больших баз данных) и способствует повторному использованию дизайна благодаря обеспечению решений часто встречающихся проблем. Архитектурные стили и шаблоны можно рассматривать как набор принципов, формирующих приложение.

Слой – позволяет разделить функциональность системы на отдельные разделы – слои. Например – слой представления, бизнес-слой, слой доступа к данным, слой сервисов

Основные термины -

Аутентификация

 Авторизация

 Кэширование

 Сетевое взаимодействие

 Управление конфигурацией

 Управление исключениями

 Протоколирование и инструментирование

 Управление состоянием

 Валидация

Аутентификация

Проектирование эффективной стратегии аутентификации имеет большое значение с точки зрения обеспечения безопасности и надежности приложения, в противном случае, оно будет уязвимым для атак с подделкой пакетов, атак перебором по словарю, перехватом сеансов и других типов атак. При проектировании стратегии аутентификации руководствуйтесь следующими рекомендациями:

 Определите границы доверия и проводите аутентификацию пользователей и вызовов на границах доверия. Учтите, что может понадобиться аутентифицировать вызовы, как клиента, так и сервера (взаимная аутентификация).

 Обеспечьте использование надежных паролей или парольных фраз.

 При наличии множества систем в рамках приложения, или если пользователи должны иметь возможность доступа ко многим приложениям, используя одни и те же учетные данные, применяйте стратегию единой регистрации.

 Не передавайте пароли по сети и не храните их в базе данных или хранилище данных в открытом виде. Храните хеш пароля.

Больше сведений о разработке стратегии аутентификации и методиках ее реализации можно найти в разделе «Дополнительные источники» в конце данной главы.

Авторизация

Проектирование эффективной стратегии авторизации имеет большое значение с точки зрения обеспечения безопасности и надежности приложения, в противном случае, оно будет уязвимым для разглашения сведений, повреждения или подделки данных и несанкционированного получения прав. При проектировании стратегии авторизации руководствуйтесь следующими рекомендациями:

 Определите границы доверия и проводите авторизацию пользователей и вызовов на границах доверия.

 Защитите ресурсы, проводя авторизацию вызывающей стороны на основании ее удостоверения, групп или ролей. Обеспечьте минимальное дробление, по возможности ограничивая количество используемых ролей.

 Применяйте авторизацию на основании ролей для бизнес-решений. При авторизации на основании ролей все пользователи распределяются по группам (ролям), что позволяет задавать права доступа для роли, а не для каждого

пользователя в отдельности. Это упрощает управление, поскольку администратору приходится работать лишь с небольшим набором ролей, а не со всеми пользователями системы.

 Применяйте авторизацию на базе ресурсов для аудита системы. При авторизации на базе ресурсов права доступа определяются в самом ресурсе. Например, список управления доступом (ACL) ресурса Windows использует удостоверение исходного вызывающего для определения его прав доступа к ресурсу. При использовании авторизации на базе ресурсов в WCF необходимо выполнить олицетворение исходного вызывающего через клиента или слой представления, через слой сервисов WCF и для кода бизнес-логики, выполняющего доступ к ресурсу.

 Используйте авторизацию на основании утверждений, если требуется поддерживать интегрированную авторизацию на базе сочетания данных, таких как удостоверение, роль, разрешения, права и т.д. Авторизация на основании утверждений обеспечивает дополнительные уровни абстракции, что упрощает отделение правил авторизации от механизма авторизации и аутентификации. Например, пользователь может быть аутентифицирован по сертификату или имени пользователя/паролю, после чего набор этих утверждений передается в сервис для определения прав доступа к ресурсу.

Больше сведений о разработке стратегии авторизации и методиках ее реализации можно найти в разделе «Дополнительные источники» в конце данной главы.

Кэширование

Кэширование может улучшить производительность и время отклика приложения. Однако неправильно спроектированная стратегия кэширования может негативно сказаться на этих показателях. Кэширование должно применяться для оптимизации поиска используемых данных, сокращения количества обращений к сети и предотвращения ненужной или повторной обработки. При реализации кэширования необходимо принять решение о том, когда загружать кэшированные данные, а также как и когда удалять устаревшие кэшированные данные. Предварительная асинхронная загрузка в кэш часто используемых данных или применение пакетной обработки помогут избежать задержек на стороне клиента. При проектировании стратегии кэширования руководствуйтесь следующими рекомендациями:

 Выберите подходящее размещение для кэша. Если приложение развертывается на Веб-ферме, избегайте применения локальных кэшей, для которых необходима синхронизация. В этом случае рекомендуется использовать систему управления транзакционными ресурсами, такую как Microsoft® SQL Server®, или продукт, поддерживающий распределенное кэширование, такой как технология Memcached производства компании Danga Interactive или механизм кэширования Velocity от компании Microsoft (больше информации по этому вопросу можно найти в разделе Дополнительные источники в конце данной главы).

 При работе с кэшем в памяти применяйте кэширование данных в готовом к использованию виде. Например, кэшируйте не просто необработанные данные

базы данных, а используйте специализированные объекты необходимые приложению. Реализуйте кэширование в памяти с помощью Microsoft Velocity.

 Не кэшируйте часто изменяющиеся данные и незашифрованные конфиденциальные данные.

 Не полагайтесь на кэшированные данные, они могут быть удалены. Реализуйте механизм обработки сбоев кэша, возможно, путем повторной загрузки элемента из источника.

 Будьте особенно осторожны при работе с кэшем из нескольких потоков. В случае использования множества потоков для обеспечения непротиворечивости данных убедитесь, что любой доступ к кэшу является потокобезопасным.

Более подробно разработка стратегии кэширования рассматривается в разделе «Этапы проектирования стратегии кэширования» далее в этой главе.

Сетевое взаимодействие

Средства связи обеспечивают взаимодействие компонентов разных слоев и уровней. Выбор механизма связи зависит от сценариев развертывания, которые должно поддерживать ваше приложение. При проектировании стратегии связи руководствуйтесь следующими рекомендациями

 Используйте взаимодействие посредством обмена сообщениями при пересечении физических границ или границ процесса; и взаимодействие объектов внутри процесса (при пересечении только логических границ). Для сокращения числа циклов запрос-ответ и повышения производительности взаимодействия через физические границы и границы процесса, проектируйте обобщенные интерфейсы, взаимодействующие не так часто, но передающие большие объемы данных при каждом взаимодействии. Тем не мене, там где это необходимо, предоставляйте детализированные интерфейсы, которые будут использоваться вызовами внутри процесса, и заключайте эти вызовы в обобщенный фасад, который будет использоваться процессами, выполняющими доступ к нему через физические границы или границы процессов.

 Если порядок получения сообщений не имеет значения, и сообщения не зависят друг от друга, используйте асинхронное взаимодействие. Это поможет избежать блокировки обработки или потоков UI.

 Используйте механизм Microsoft Message Queuing, обеспечивающий помещение сообщений в очередь для их отложенной доставки в случае сбоя системы или разрыва подключения. Message Queuing может осуществлять транзакционную доставку сообщений и поддерживает гарантированную одноразовую доставку.

 Выбирайте соответствующий транспортный протокол, такой как HTTP для связи через Интернет и TCP для связи по внутренней сети. Продумайте соответствующие схемы обмена сообщениями, то, будете ли вы использовать взаимодействие с установлением подключения или без установления подключения, поддержку

гарантий надежности (такие как соглашения на уровне сервиса) и механизм аутентификации.

 Обеспечьте защиту сообщений и конфиденциальных данных при передаче, используя шифрование, цифровые сертификаты и функции безопасности каналов.

Более подробно проектирование стратегии взаимодействия рассматривается в главе 18, «Взаимодействие и обмен сообщениями».

Управление конфигурацией

Правильный выбор механизма управления конфигурацией имеет большое значение с точки зрения обеспечения безопасности и надежности приложения, в противном случае, оно будет уязвимым для различных атак. Также неправильный механизм управления конфигурацией может обусловливать издержки на администрирование приложения. При проектировании стратегии управления конфигурацией руководствуйтесь следующими рекомендациями:

 Тщательно продумывайте, какие параметры должны быть конфигурируемыми извне. Убедитесь в реальной прикладной целесообразности каждого настраиваемого параметра и обеспечьте минимум параметров конфигурации, необходимый для выполнения этих требований. Излишняя настраиваемость может усложнить систему и сделать ее уязвимой из-за брешей безопасности и неправильного функционирования, обусловленных неверной конфигурацией.

 Примите решение о том, будут ли сведения о конфигурации храниться централизованно и загружаться или применяться к пользователям при запуске (например, через Active Directory Group Policy1). Продумайте, как обеспечите ограничение доступа к сведениям о конфигурации. Используйте менее привилегированный процесс и учетные записи сервиса и шифруйте конфиденциальные данные в хранилище конфигурации.

 Распределите элементы конфигурации по логическим разделам на основании того, являются ли они настройками пользователя, приложения или среды. Это упростит разделение конфигурации, если потребуется поддерживать разные настройки для разных наборов пользователей или множества сред.

 При наличии множества уровней в приложении распределите элементы конфигурации по логическим разделам. Если сервер приложений выполняется на Веб-ферме, определите, какая часть конфигурации является общей, и какая часть применяется исключительно к компьютеру, на котором выполняется приложение. После этого выберите соответствующее хранилище конфигурации для каждого раздела.

 Предоставьте отдельный административный UI для редактирования конфигурационных данных.

управление исключениями

Проектирование эффективной стратегии управления исключениями имеет большое значение с точки зрения обеспечения безопасности и надежности приложения. Неправильный выбор стратегии очень усложнит диагностирование и решение проблем приложения, сделает его уязвимым для атак типа отказ в обслуживании (DoS), а также может привести к разглашению конфиденциальных и важных сведений. Формирование и обработка исключений является ресурсоемким процессом, поэтому важно, чтобы при проектировании были также учтены вопросы производительности. Хорошим подходом является проектирование централизованного механизма управления исключениями для приложения и предоставление точек доступа к системе управления исключениями (таких как события WMI) для обеспечения поддержки систем мониторинга уровня предприятия, таких как Microsoft System Center. При проектировании стратегии управления исключениями руководствуйтесь следующими рекомендациями:

 Проектируйте соответствующую стратегию распространения исключений, которая обеспечивает обертывание или замену исключений или внесение необходимых дополнительных данных. Например, позвольте исключениям распространяться вверх к граничным слоям, где они могут быть запротоколированы и преобразованы должным образом для передачи в следующий слой. Применяйте контекстные идентификаторы, это позволит находить взаимосвязанные исключения в разных слоях при проведении анализа основных причин ошибок и сбоев. Также убедитесь, что в дизайне предусмотрены необрабатываемые исключения. Перехватывайте внутренние исключения, только если можете обработать их или должны добавить некоторые данные. Не используйте исключения для управления логикой приложения.

 Обеспечьте, чтобы приложение не оставалось в нестабильном состоянии после сбоя, и чтобы исключения не приводили к разглашению конфиденциальных данных или сведений о процессе. Если не можете гарантированно обеспечить корректное восстановление после сбоя, позвольте приложению завершиться с необработанным исключением; это лучше, чем оно будет продолжать выполнение в неизвестном и, возможно, поврежденном состоянии.

 Выработайте соответствующую стратегию протоколирования и уведомления для критических ошибок и исключений, обеспечивая сохранение достаточно детальных сведений об исключении. Это позволит техническому персоналу восстановить сценарий, который привел к исключению. Однако не предоставляйте конфиденциальные данные в сообщениях об исключениях и файлах журнала.

Более подробно проектирование стратегии управления исключениями рассматривается в разделе «Этапы проектирования стратегии управления исключениями» далее в этой главе.

Протоколирование и инструментирование

Проектирование эффективной стратегии протоколирования и инструментирования имеет большое значение с точки зрения обеспечения безопасности и надежности приложения, в противном случае, пользователи смогут безнаказанно отказываться от своих действий. Также

файлы журналов могут пригодиться для доказательства правонарушений в случае судебного разбирательства. Аудит и протоколирование действий во всех слоях приложения необходимы, потому что могут помочь обнаружить подозрительные действия и обеспечить раннее выявление серьезных атак. Аудит считается наиболее достоверным, если данные аудита формируются непосредственно в момент доступа к ресурсу и именно теми процедурами, которые выполняют доступ к ресурсу. Инструментирование можно реализовать, используя счетчики производительности и события, обеспечивающие администраторов сведениями о состоянии, производительности и работоспособности приложения. При проектировании стратегии протоколирования и инструментирования руководствуйтесь следующими рекомендациями:

 Проектируйте централизованный механизм протоколирования и инструментирования, обеспечивающий перехват критически важных для системы и бизнеса событий. Избегайте слишком детализированного протоколирования и инструментирования, но предусмотрите дополнительные функции протоколирования и инструментирования, настраиваемые во время выполнения, для получения дополнительных данных и для помощи при отладке.

 Создавайте политики безопасного управления файлами журнала. Не храните конфиденциальные данные в файлах журнала и защищайте их от неавторизованного доступа. Продумайте, как обеспечить безопасный доступ и передачу данных аудита и протоколирования между слоями приложения, и обеспечьте сдерживание и правильную обработку сбоев протоколирования.

 Сделайте свои приемники журнала, или слушатели трассировки, настраиваемыми, чтобы обеспечить возможность их изменения во время выполнения соответственно требованиям инфраструктуры развертывания. В реализации протоколирования и инструментирования в приложении очень помогут такие библиотеки, как Enterprise Library группы patterns & practices. Среди популярных библиотек можно также упомянуть NLog и log4net (больше информации по этому вопросу можно найти в разделе Дополнительные источники в конце данной главы)

Более подробно протоколирование и инструментирование рассматриваются в разделе «Этапы проектирования стратегии управления исключениями» далее в этой главе.

Управление состоянием

Управление состоянием – это вопросы, связанные с хранением данных, представляющих состояние компонента, операции или этапа процесса. Для хранения данных состояния могут использоваться разные форматы и хранилища. Механизм управления состоянием может оказывать влияние на производительность приложения; сохранение даже небольших объемов данных состояния может неблагоприятно сказываться на производительности приложения и его способности масштабироваться. Сохраняться должны только необходимые данные, и вы должны понимать, какие варианты управления состоянием допустимы. При проектировании стратегии управления состоянием руководствуйтесь следующими рекомендациями:

 Сохраняйте минимальный объем данных состояния.

 Если для сохранения или совместного использования данные состояния должны передаваться через границы процессов и сетей, обеспечьте их сериализуемость.

 Правильно выбирайте хранилище состояния. Хранение состояния в процессе или в памяти обеспечит наилучшую производительность, но эта техника может использоваться, только если состояние не должно сохраняться между повторными запусками процесса или системы. Если хотите, чтобы данные состояния были доступны после перезапуска процесса или системы, сохраняйте их на локальном диске или локальном SQL Server. Если состояние является критически важным аспектом приложения, или если данные состояния должны использоваться совместно несколькими компьютерами, храните состояние централизованно, например, на выделенном SQL Server.

Валидация

Проектирование эффективного механизма валидации имеет большое значение с точки зрения обеспечения удобства и простоты использования и надежности приложения, в противном случае, оно может остаться открытым для несогласованности данных и нарушений бизнес-правил, а также обеспечивать неудовлетворительный уровень взаимодействия с пользователем. Кроме того, приложение может оказаться уязвимым к таким угрозам безопасности, как межсайтовые атаки внедрением сценариев, атаки типа внедрение SQL-кода, переполнение буфера и другие атаки посредством входных данных. Четкого и исчерпывающего определения действительного или злонамеренного ввода нет. Возможные риски, обуславливаемые злонамеренным вводом, зависят также от того, как приложение использует ввод. При проектировании стратегии валидации руководствуйтесь следующими рекомендациями:

 По возможности реализуйте позитивную валидацию с использованием списков разрешенного ввода. Намного проще расширить список разрешенного ввода, чем пытаться определить все варианты некорректного ввода.

 Для проверки безопасности не полагайтесь только на проверку на стороне клиента. Используйте проверку на стороне клиента для обеспечения обратной связи пользователю и улучшения взаимодействия с пользователем. Всегда проверяйте ввод на наличие неверных или злонамеренных данных на стороне сервера, поскольку проверка на стороне клиента может быть без труда подделана.

 Если необходимо обеспечить повторное использование подхода к валидации, реализуйте его централизованно, вынося функциональность валидации в отдельные компоненты, или обратитесь к библиотекам сторонних производителей, таким как Enterprise Library Validation Block (Блок валидации Enterprise Library) группы patterns & practices. Это позволит создать единый механизм валидации для всех слоев и уровней приложения.

 Ограничивайте, отклоняйте и очищайте пользовательский ввод. Иначе говоря, исходите из предположения о том, что весь пользовательский ввод является злонамеренным. Определите границы доверия и проверяйте длину

Стандартные архитектуры по

Основные вопросы при разработке архитектуры по:

Как пользователь будет использовать приложение?

• Как приложение будет развертываться и обслуживаться при эксплуатации?

• Какие требования по атрибутам качества, таким как безопасность, производительность, возможность параллельной обработки, интернационализация и конфигурация, выдвигаются к приложению?

• Как спроектировать приложение, чтобы оно оставалось гибким и удобным в обслуживании в течение долгого времени?

• Основные архитектурные направления, которые могут оказывать влияние на приложение сейчас или после его развертывания?

Основные проблемы

К потенциальным проблемам относятся появление новых технологий и критически важные бизнес-требования. Например, «Могу ли я переходить с одного сервиса стороннего производителя к другому?», «Могу ли я добавить поддержку нового типа клиента?», «Могу ли я быстро менять бизнес-правила оплаты услуг?» и «Могу ли я перейти к новой технологии для компонента Х?». Несмотря на то, что это крайне обобщенные аспекты, как правило, при реализации они (и другие зоны риска) проецируются в параметры качества и сквозную функциональность.

Параметры качества

Параметры качества – это общие свойства архитектуры, которые оказывают влияние на поведение во время выполнения, дизайн системы и взаимодействие с пользователем. Та степень, с которой приложение обеспечивает требуемое сочетание параметров качества, таких как удобство и простота использования, производительность, надежность и безопасность, определяет успешность дизайна и общее качество программного продукта.

Следующий список систематизирует сведения о параметрах качества и помогает понять, на какие сценарии их влияние наиболее вероятно:

 Общесистемные качества. Общие качества системы в целом, такие как возможность технической поддержки и тестируемость.

 Качества времени выполнения. Качества системы, проявляемые непосредственно во время выполнения, такие как доступность, возможность взаимодействия с другими системами, управляемость, производительность, надежность, масштабируемость и безопасность.

 Конструктивные качества. Качества, отражающие дизайн системы, такие как концептуальная целостность, гибкость, удобство и простота обслуживания и возможность повторного использования.

 Пользовательские качества. Удобство и простота использования системы.

Сквозная функциональность

Сквозная функциональность – это аспекты дизайна, которые могут применяться ко всем слоям, компонентам и уровням. Также это те области, в которых чаще всего делаются ошибки, имеющие большое влияние на дизайн. Приведем примеры сквозной функциональности:

 Аутентификация и авторизация. Как правильно выбрать стратегию аутентификации и авторизации, передачи идентификационных данных между слоями и уровнями и хранения удостоверений пользователей.

 Кэширование. Как правильно выбрать технику кэширования, определить данные, подлежащие кэшированию, где кэшировать данные и как выбрать подходящую политику истечения срока действия.

 Связь. Как правильно выбрать протоколы для связи между слоями и уровнями, обеспечения слабого связывания между слоями, осуществления асинхронного обмена данными и передачи конфиденциальных данных.

 Управление конфигурацией. Как выявить данные, которые должны быть настраиваемыми, где и как хранить данные конфигурации, как защищать конфиденциальные данные конфигурации и как обрабатывать их в серверной ферме или кластере.

Управление исключениями. Как обрабатывать и протоколировать исключения и обеспечивать уведомления в случае необходимости.

 Протоколирование и инструментирование. Как выбрать данные, подлежащие протоколированию, как сделать протоколирование настраиваемым, и как определить необходимый уровень инструментирования.

 Валидация. Как определить, где и как проводить валидацию; как выбрать методики для проверки длины, диапазона, формата и типа; как предотвратить и отклонить ввод недопустимых значений; как очистить потенциально злонамеренный и опасный ввод; как определить и повторно использовать логику валидации на разных слоях и уровнях приложения.

Тестируемость – это мера того, насколько легко создавать критерии проверки для системы или компонентов и насколько хорошо они подвергаются тестированию на соответствие этим критериям. Учитывать аспекты тестируемости при проектировании архитектуры необходимо

для того, чтобы обеспечить раннюю диагностику проблем и, таким образом, сократить затраты на обслуживание. Для обеспечения тестируемости:

 Четко определяйте ввод и вывод слоев и компонентов приложения уже на этапе проектирования.

 Используйте для слоя представления шаблоны отделения представления, такие как MVC или MVP. Это обеспечит возможность модульного тестирования логики представления.

 Реализуйте бизнес-логику и рабочие процессы в отдельном бизнес-слое, что улучшит тестируемость приложения.

 Проектируйте слабо связанные компоненты, которые можно тестировать по отдельности.

 Выработайте эффективную стратегию протоколирования и трассировки, что позволит выявлять или диагностировать ошибки, которые в противном случае было бы сложно найти. Обеспечьте данные протоколирования и трассировки, которые могут использоваться средствами мониторинга или управления. Это поможет обнаруживать дефектный код при возникновении ошибок. Файлы журнала должны содержать сведения, которые можно использовать для воссоздания проблемы.

Варианты решений

Определив основные проблемы, можно приступать к созданию исходной базовой архитектуры и ее детализации для получения возможного варианта архитектуры. В ходе этого процесса можно использовать пилотные архитектуры для более подробного рассмотрения определенных областей дизайна или для проверки новых идей. Затем выполняется проверка нового варианта архитектуры на соответствие основным сценариям и заданным требованиям и вновь повторяется итеративный цикл по доработке дизайна.

Базовая архитектура описывает существующую систему, то как она выглядит сегодня. Для нового проекта исходная базовая архитектура – это первое высокоуровневое представление архитектуры, на основании которого будут создаваться возможные варианты архитектуры. Возможный вариант архитектуры включает тип приложения, архитектуру развертывания, архитектурный стиль, выбранные технологии, параметры качества и сквозную функциональность.

Итеративный и инкрементный подход позволяет избавиться от крупных рисков сначала, итеративно формировать архитектуру и через тестирование подтверждать, что каждая новая базовая архитектура является улучшением предыдущей.

Пилотная архитектура (architectural spike) – это тестовая реализация небольшой части общего дизайна или архитектуры приложения. Ее назначение – анализ технических аспектов конкретной части решения для проверки технических допущений, выбора дизайна из ряда возможных вариантов и стратегий реализации или иногда оценка сроков реализации.

Анализ архитектуры приложения – критически важная задача, поскольку позволяет сократить затраты на исправление ошибок, как можно раньше выявить и исправить возможные проблемы. Анализ архитектуры следует выполнять часто: по завершении основных этапов проекта и в ответ на существенные изменения в архитектуре. Создавайте архитектуру, помня об основных вопросах задаваемых при таком анализе, это позволит как улучшить архитектуру, так и сократить время, затрачиваемое на каждый анализ.

16. Организация проектирования и разработки ПО []

Готовый ответ Маши

Стандартные приемы и шаблоны при проектировании ПО.

Архитектурный стиль, иногда называемый архитектурным шаблоном – это набор принципов, высокоуровневая схема, обеспечивающая абстрактную инфраструктуру для семейства систем. Архитектурный стиль улучшает секционирование(разделение хранимых объектов баз данных (таких как таблиц, индексов, материализованных представлений) на отдельные части с раздельными параметрами физического хранения. Используется в целях повышения управляемости, производительности и доступности для больших баз данных) и способствует повторному использованию дизайна благодаря обеспечению решений часто встречающихся проблем. Архитектурные стили и шаблоны можно рассматривать как набор принципов, формирующих приложение.

Приемы увеличения производительности

Производительность – это функция как дизайна слоя доступа к данным, так и дизайна базы данных. Для обеспечения максимальной пропускной способности при настройке системы

рассматривайте их вместе. При проектировании производительности руководствуйтесь следующими рекомендациями:

 Используйте пул подключений и оптимизируйте производительность, исходя из результатов, полученных при моделировании нагрузочных сценариев.

 Рассмотрите возможность настройки уровней изоляции для запросов к данным. Для приложения с высокими требованиями по пропускной способности специальные операции с данными могут выполняться на более низких уровнях изоляции, чем вся остальная транзакция. Комбинирование различных уровней изоляции может иметь негативное влияние на непротиворечивость данных, поэтому необходимо тщательно анализировать этот аспект для каждого отдельного случая.

 Выполняйте пакетирование команд, чтобы сократить количество обращений к серверу базы данных.

 Для нечасто меняющихся данных используйте оптимистическую блокировку. Это позволит сократить издержки на блокировку строк базы данных, в том числе и на подключение, которое должно оставаться открытым в течение всей блокировки.

 В случае применения DataReader используйте последовательный поиск, это обеспечит большую производительность.

Кэширование – один из лучших механизмов повышения производительности приложений и сокращения времени отклика UI. Кэширование данных в слое представления позволит оптимизировать поиск данных и избежать повторных сетевых вызовов, а также обеспечит возможность сохранять результаты ресурсоемких или часто повторяющихся процессов во избежание ненужной повторной обработки.

Приемы увеличения надежности

Аудит и протоколирование. Кто, что сделал и когда? Приложение функционирует в нормальном режиме? Аудит занимается вопросами регистрации событий, связанных с безопасностью. Протоколирование касается того, как приложение публикует данные о своей работе.

 Аутентификация. Кто вы? Аутентификация – это процесс, при котором одна сущность четко и однозначно идентифицирует другую сущность, обычно это делается с помощью таких учетных данных, как имя пользователя и пароль.

 Авторизация. Что вы можете делать? Авторизация определяет, как приложение управляет доступом к ресурсам и операциям.

 Управление конфигурацией. В каком контексте выполняется приложение? К каким базам данных подключается? Как выполняется администрирование приложения? Как защищены эти настройки? Управление конфигурацией определяет, как приложение реализует эти операции и задачи.

 Шифрование. Как реализована защита секретов (конфиденциальных данных)? Как осуществляется защита от несанкционированного доступа данных и библиотек (целостности)? Как передаются случайные значения, которые должны быть

криптографически стойкими? Шифрование и криптография занимается вопросами реализации конфиденциальности и целостности.

 Обработка исключений. Что делает приложение при сбое вызова его метода? Насколько полные данные об ошибке оно предоставляет? Обеспечивает ли оно понятные для конечных пользователей сообщения об ошибках? Возвращает ли оно ценные сведения об исключении вызывающей стороне? Выполняется ли корректная обработка произошедшего сбоя? Предоставляет ли приложение администраторам необходимую информацию для проведения анализа основных причин сбоя? Обработка исключений касается того, как исключения обрабатываются в приложении.

 Валидация входных данных. Как определить, что поступаемые в приложение данные действительные и безопасные? Выполняется ли ограничение ввода через точки входа и кодировка вывода через точки выхода? Можно ли доверять таким источникам данных, как базы данных и общие файлы? Проверка ввода касается вопросов фильтрации, очистки или отклонения вводимых в приложение данных перед их дополнительной обработкой.

 Конфиденциальные данные. Как приложение работает с конфиденциальными данными? Обеспечивает ли оно защиту конфиденциальных данных пользователей и приложения? Здесь решаются вопросы обработки приложением любых данных, которые должны быть защищены либо при хранении в памяти, либо при передаче по сети, либо при хранении в постоянных хранилищах.

 Управление сеансами. Как приложение обрабатывает и защищает сеансы пользователей?

Сеанс – это ряд взаимосвязанных взаимодействий пользователя и приложения.

Резервное копирование

Резервное копирование выполняется для того, чтобы можно было:

• Восстанавливать отдельные файлы

• Восстанавливать целиком файловые системы.

Частота изменения данных очень важна для разработки процедуры резервного копирования. Тому есть две причины:

• Резервная копия — это не больше чем снимок копируемых данных. Это отражение данных в определённый момент времени.

• И чем чаще меняются данные, тем чаще следует выполнять их резервное копирование.

Чтобы выполнять резервное копирование, прежде всего, нужно иметь подходящую программу. Эта программа должна не только уметь делать простые копии данных на резервные носители, но и хорошо подходить для сотрудников вашей организации и требований бизнеса. Оценивая программы для резервного копирования, следует обратить внимание на:

• Возможности выполнения резервного копирования по расписанию

• Управление размещением, циклами копий и использованием носителей

• Взаимодействие с операторами (и/или автоматическими устройствами смены носителей), когда требуется определённый носитель

• Возможности, облегчающие поиск носителя с определённой копией заданного файла.

Требования к системе резервного копирования

• Надёжность хранения информации — обеспечивается применением отказоустойчивого оборудования систем хранения, дублированием информации и заменой утерянной копии другой в случае уничтожения одной из копий (в том числе как часть отказоустойчивости).

• Простота в эксплуатации — автоматизация (по возможности минимизировать участие человека: как пользователя, так и администратора).

• Быстрое внедрение — простая установка и настройка программ, быстрое обучение пользователей.

Системы резервного копирования должны быть способны быстро восстановить данные, надежно хранить резервные копии, а также легко интегрироваться в вычислительные системы и обладать расширенными функциями автоматизации создания копий.