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

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

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

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

 

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

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

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

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

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

 

Ещё риски:

  1. Дефицит специалистов.
  2. Нереалистичные сроки и бюджет.
  3. Реализация несоответствующей функциональности.
  4. Разработка неправильного пользовательского интерфейса.
  5. «Золотая сервировка», перфекционизм, ненужная оптимизация и оттачивание деталей.
  6. Непрекращающийся поток изменений.
  7. Нехватка информации о внешних компонентах, определяющих окружение системы или вовлечённых в интеграцию.
  8. Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.
  9. Недостаточная производительность получаемой системы.
  10. «Разрыв» в квалификации специалистов разных областей знаний.

 

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

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

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

XP

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

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

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

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

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

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

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

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

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

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

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

И .тд.


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

№ Билет № Формулировка ответа Преподаватель Кто делает ответ Состояние
5.3., 26.3., 39.2. Организация проектирования и разработки программного обеспечения. Стандартные архитектуры ПО. Основные термины, основные проблемы, стандартные решения, основные критерии качества архитектуры, тестирование архитектуры. Алексеев Пётр Сергеевич Маша Сергеева Готовый ответ Маши

 

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

Определение

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

 

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

 

· Разделение функций. Разделите приложение на отдельные компоненты с, по возможности, минимальным перекрытием функциональности. Важным фактором является предельное уменьшение количества точек соприкосновения, что обеспечит высокую связность (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. При проектировании стратегии управления исключениями руководствуйтесь следующими рекомендациями:

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

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

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

 

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