Правила войны и систем

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

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

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

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

— График работ — это не поле для политики.

— Остановка проекта равносильна его смерти.

— Чтобы попасть в цель — надо ее видеть.

— Стандартизация способствует нестандартным решениям.

— Повторное использование результатов работы.

— Изучай историческую науку.

— На все должна быть бумажка.

— Нужно учиться общаться.

— Без мотивации проект — это процесс.

— Самые правильные решения — простые

— [IE 21.06.05 г.].

Правила Мацяшека разработки систем

Анализ требований и проектирование систем. Лешек Мацяшек

Maciashek_31

Тестирование

Группа качества должна состоять из лучших специалистов, имеющихся в организации. Группа никак не должна быть связана с проектом, за исrлючением своей роли по обеспечению проекта. Группа (а не истинные разработчики!) несет ответственность за конечное качество продукта. [392]

Maciashek_30

Тестирование

Тот, кто разрабатывает сервис менее всего заинтересован в том, чтобы в программе реализующей этот сервис, были обнаружены ошибки. [391]

Maciashek_29

Нормализация баз данных

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

Нормализация — декомпозиция отношения. 1НФ — таблица содержит логически неделимые значения (скаляры) 2НФ — 1НФ + неключевые элементы завиcят от первичного ключа. 3НФ — 2НФ неключевые элементы взаимно независимы, каждый ключевой элемент неприводимо зfвисит от первичного ключа.

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

Если БД отличается статичным характером, т.е. часто выполняется поиск, а обновление производится время от времени, приобретает смысл денормализация БД, т.е. поиск в таблице большого размера более эффективен, чем поиск в нескольких таблицах, которые следует объединить перед поиском. [351]

Maciashek_28

Данные остаются навсегда, а приложения появляются и исчезают. [239]

Maciashek_27

Использование CASE-средств для повышения личной продуктивности всегда оправдано.

Широкомасштабное применение CASE-технологии может стать препятствием на пути разработки системы в технологически незрелых организациях. [144]

Maciashek_26

Не существует рецепта отыскания и определения наилучших классов.

Факторы определяющие успешное проектирование классов:

— знания в области моделирования классов;

— — понимание проблемной области;

— — опыт в области аналогичных и успешных проектов;

— — способность смотреть вперед и предвидеть последствия решений;

— — готовность к пересмотру модели с целью устранения недостатков (связано с использованием CASE-средств).

Maciashek_25

Большие проекты связаны с управлением большими массивами требований. Для таких проектов весьма существенным моментом является обозначение и классификация формулировок требований. Затем можно определить иерархию требований. [139]

Maciashek_24

В проблемной области можно довольно неплохо разобраться с помощью изучения документов и форм, используемых в процессах делопроизводства. При возможности следует включать в документ заполненные формы — «пустые» формы не дают такого же уровня понимания бизнес-процессов. [139]