| Всё о задаче AdminP. Часть вторая Во второй части мы завершаем рассмотрение AdminP. В ней рассмотрены запросы междоменного администрирования и способы управления функциями AdminP с помощью настроек документа сервера, команд консоли сервера, файла Notes.ini и интервалов очистки базы данных. В этой статье предполагается, что вы опытный администратор Domino и прочитали первую часть |
|
|
| |
| Всё о задаче AdminP. Proxy-действия в R5 и Domino 6 Приложение к статье об административном процессе |
|
|
| |
| Всё о задаче AdminP. Часть первая Перевод классической статьи 2003-его года о задаче административного процесса (AdminP). Очень полезна для понимания работы механизма этой задачи. В первой части статьи описаны компоненты задачи AdminP, как они работают, и как их использование помогает сделать работу администратора Domino проще. Задача AdminP (сакращённо от Administration Process, Административный процесс) работает с базой административных запросов (Administration Requests, admin4.nsf) |
|
|
| |
|
Главная Библиотека СоветыКак оценить риск?
Степан Карандин
Проект это некая деятельность, имеющая некоторые качественные и количественные характеристики:
Четкая цель. Успех проекта невозможен без знания, при каком конечном результате реализация проекта может быть признана успешным.
Временные рамки. Начало и окончание проекта должны быть четко определены по времени.
Комплексность поставленной цели. Проект включает в себя взаимосвязанные задачи, часто характеризующиеся разными областями деятельности .
Ресурсы. Для выполнения проекта необходимы специалисты, а также целый перечень средств и активов(в случае проектов по внедрению или разработке информационных систем - ИС), инфраструктура(компьютеры, коммуникации и т.п.).
Фактор риска при разработке ПО - это условия, которые либо повышают, либо понижают вероятность успешного завершения проекта. В случае разработки приложений под IBM Lotus Domino/Notes эти факторы могут быть поделены на шесть категорий.
Технологии, используемые при разработке и внедрении.
Эта категория рисков относится к инструментарию, т.е. программному и аппаратному обеспечению, используемому участником проекта для выполнения своей работы. Обычно, коллективы разработчиков выбирают какой-то инструментарий и пользуются им вплоть до морального устаревания. Но в том случае, если новый проект требует каких-либо качеств от инструментов команды, приходится использовать что-то непривычное. Например, тестер привык пользоваться обычным бумажным блокнотом для своих записей и выполняет все тесты вручную, и пока он научится и привыкнет пользоваться средствами для автоматического тестирования результаты его работы непрогнозируемы.
Высокий уровень риска: предполагается использование новых средств разработки и тестирования.
Средний уровень: предполагается использование средств разработки и тестирования, с которыми знакомы не все участники.
Низкий уровень: использование новых средств разработки и тестирования не предполагается.
Степень интегрированности с внешним окружением.
Чем сложнее связи с внешним окружением ИС, тем сложнее добиться их качественной реализации. Например, если в поставленной задаче имеется условие, что пользователь должен получать доступ к данным через веб-браузер, то это означает, что разработчик, неоднократно реализовывавший эту функцию, практически наверняка не столкнется с трудностями. В том случае, если идет речь об интеграции IBM Lotus Domino/Notes c ПО от 1С, то существует множество подводных камней, которые могут привести к краху проекта.
Высокий уровень: предполагается двухсторонний обмен информацией, управляемый некой логикой, с меняющимися правилами и структурой данных.
Средний уровень: предполагается реализация двухстороннего обмена данными, не предполагающего их обработки в процессе приема-передачи.
Низкий уровень: предполагается одностороннее движение данных, например, импорт с помощью ODBC.
Наличие специалистов, а также уровень их подготовленности.
Чем больше опыт разработчика, тем меньше времени ему требуется на решение возникающих проблем. В том случае, если у вас нет опытного разработчика, или разработчик участвует еще в паре-тройке других проектов, то шансы не достичь результата очень высоки.
Думать о количестве участников, а также уровне их подготовки необходимо до начала проекта, привлечением большего количества людей вы можете только навредить (Ф.Брукс, "Мифический человеко-месяц").
Высокий уровень: имеется недостаточное количество специалистов, и кто-то достаточно компетентен для выполнения назначенных ему ролей
Средний уровень: имеется достаточное количество специалистов, но кто-то некомпетентен, или наоборот, все хорошо подготовлены, но людей не хватает
Низкий уровень: имеется достаточное количество специалистов, каждый из них достаточно компетентен для выполнения назначенных ему ролей
Наличие экспертов предметной области
Любой проект разработки или внедрения ИС своей конечной целью имеет автоматизацию какой-либо деятельности. Для того, чтобы автоматизация была успешна, вам потребуется кто-то, кто расскажет, что именно должна "уметь" система. Такие "рассказчики" называются экспертами предметной области.
Высокий уровень: экспертов предметной области по отдельным участкам ИС нет, или работа с ними крайне затруднительна (например, эксперт территориально удален)
Средний уровень: эксперты предметной области в наличии, но в случае болезни или занятости эксперта вам приходится ждать, когда он станет доступен
Низкий уровень: имеется достаточное количество экспертов предметной области, и болезни, командировки, занятость отдельных специалистов не будет помехой ходу работ
Сложность и стабильность бизнес-процессов
Бизнес-процессы, которые подлежат автоматизации могут быть простыми, когда бизнес-сущности и деятельность могут быть легко формализованы,описаны и реализованы в ИС. В том случае, если бизнес-процессы включают в себя многоуровневую обработку данных, основанную на различных проверках, их реализация потребует сравнительно бОльших усилий от разработчиков и внедренцев. Также, часто изменяемые условия влекут за собой постоянные переделки в ИС, что отрицательно сказывается на ходе реализации проекта.
Высокий уровень: бизнес-процессы относительно сложные и постоянно изменяются.
Средний уровень: бизнес-процессы просты, но подвержены постоянным изменениям, или наоборот, стабильны, но относительно сложные.
Низкий уровень: бизнес-процессы относительно простые и неизменны.
Комплексность автоматизации
Если в рамках проекта необходима реализация ИС на уровне "ввод-хранение-вывод данных" в ее пределах, то это много проще, нежели интеграция разрабатываемой ИС со сторонними. Как правило, с такими сложностями можно столкнуться при попытке автоматизации более чем одного бизнес-процесса или деятельности структурного подразделения.
Высокий уровень: предстоит автоматизация нескольких бизнес-процессов или подразделений, которые могут быть автоматизированы только синхронно
Средний уровень: предстоит автоматизация нескольких бизнес-процессов или подразделений, которые могут быть автоматизированы последовательно
Низкий уровень: планируется автоматизация отдельного подразделения или бизнес-процесса
| |
 Опубликовано — 11/23/2003 |
| |
|
|
| Последнее на форуме |
 |
|
 |
|
|
