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

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

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

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]

Maciashek_23

Политические требования и юридические требования зачастую подразумеваются, чем явно формулируются в документе описания требований. Подобная ошибка может обойтись очень дорого. [138]

Maciashek_22

Документ описания требований должен создать прецендент для системы. В частности, необходимо упомянуть обо всех усилиях, приложенных для обоснования необходимости системы. [136]

Maciashek_21

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

Шаблоны для документов описания требований широко доступны. Их можно найти в учебниках, стандартах, выпускпаемых ISO, IEEE и т.д., на Web-страницах консалтинговых фирм, программных средствах разработки и т. д. Со временем каждая организация разрабатыввает свои собственные стандарты, которые соотвествуют принятой в организации практике, корпоративной культуре, кругу читателей, типам разрабатываемых систем. [135]

IEEE Recommended Practice for Software Requirements Specifications

Maciashek_20

Рамки системы

Наибольшее беспокойство при разработке доставляет так называемое «расползание рамок» системы.

Чтобы ответить на вопрос о рамках системы, необходимо знать, в каком контексте функционирует наша система.

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

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

Язык UML не обладает средствами построения визуальной модели, позволяющей определить границы системы. Поэтому зачастую для решения этой задачи прибегают к помощи контекстных диаграмм потоков данных DFD (Data Flow Diagrams) [130]

Maciashek_19

Комплекс моделей проекта

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

Бизнес-модель может быть представлена в виде трех общих диаграмм — диаграммы контекста, диаграммы бизнес-прецендентов и диаграммы бизнес-классов. [140]

Формальное моделирование требований на языке UML проводится на этапе спецификации требований.

Для установления рамок системы необходима высокоуровневая визуальная модель ключевых прецендентов и наиболее существенных классов т.н. бизнес-классы

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

Проектирование и реализация тесно переплетены и могут иницировать обратную связь с моделями спецификации требований. [129]

Maciashek_18

Управление изменениями

Требования к системе изменяются.

Изменения нельзя рассматривать как «удар», а вот неуправляемые изменения — это настоящий удар по проекту.

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

Необходима сильная стратегия управления изменениями для документирования запросов на изменения (change request), оценки влияния оказываемого изменениями (change impact).

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

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

Maciashek_17

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

Высокий риск означает, что систему трудно реализовать — не вполне ясны даже обобщенные требования. [117]

Maciashek_16

Операции принадлежат скорее к сфере проектирования, чем анализа. [45,97]

Maciashek_15

При определении того, являются ли понятия присуствующие в требованиях классами следует ответить на вопросы:

— Является ли понятие «вместилищем» данных?

— Обладает ли оно отдельными атрибутами, способными принимать разные значения?

— Можно ли создать для него множество объектов-экземпляров?

— Входит ли оно в границы прикладной области? [45,93]

Maciashek_14

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

Maciashek_13

Не «измеряя» прошлого, организация не в состоянии точно планировать будущее. [45,53]

Maciashek_12

То, что нельзя спланировать, нельзя и осуществить. [45,52]

Maciashek_11

Причины сворачивания программного обеспечения:

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

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

— Расширение ПО в будущем невозможно из-за отсуствия надлежащей документации.

— Аппаратная и/или программная платформы, на которых реализована система подлежат замене, а видимых путей для миграции нет. [45,52]

Maciashek_10

Наибольшую пользу приносят ИТ-решения стратегического уровня. Эти решения труднее всего реализовать. Именно эти системы способны обеспечить организации конкурентное преимущество.

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

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

Maciashek_9

BPR-подход к проектированию информационных систем

— Наиболее видимое различие между предприятием, ориентированным на бизнесс-процессы, и традиционной организацией состоит в существовании у каждого процесса «хозяина».

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

— результирующий проект по разработке ИС должен сосредоточиваться на реализации выявленных потоков работ. [43]

Словарь.

Maciashek_8

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

1. Оценить информационную емкость продуктов и процессов.

2. Оценить роль ИТ в отраслевой структуре.

3. Выявить и ранжировать способы, с помощью которых ИТ создает конкурентное преимущество.

4. Рассмотреть, каким образом ИТ может создавать новое направление в бизнесе.

5. Разработать план, направленный на извлечение выгод от использования ИТ. (Портер, Милар) [42]

Maciashek_7

Верно сформированная миссия отводит главное место потребностям клиентов, а не товарам или услугам которые предоставляет организация. [41]

Maciashek_6

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

Maciashek_5

Документация -> Качество

Своеобразной «лакмусовой бумагой», позволяющей проверить, насколько организация заслуживает сертификата ISO может служить ее способность создать качественный товар или обеспечить качественное обслуживание даже в том случае, если заменить весь персонал. С этой целью необходимо оформить документально и зафиксировать все виды своей деятельности. Для каждого вида деятельности должна быть определена письменная процедура, включая действия, которые необходимо выполнить в случае нарушения процесса или жалоб клиента. [37]

Maciashek_4

Качество

Цель управления качеством — сделать качество неотъемлимым свойством товара, а не проверкой того, насколько оно присуще товару. (Идеология ISO 9000) [37]

Maciashek_3

Архитектурные модули системы

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

— примерно одинаковые по размерам,

— обладать сильной внутренней связностью и

— иметь минимум взаимных пересечений (внешних связей). [35]

Maciashek_2

Масштаб программного проекта.

Самое большое влияние на организацию программного проекта оказывает его масштаб. [34]

Maciashek_1

Коллектив разработчиков

Критический фактор разработки — опыт и знания разработчиков. Хорошие разработчики могут дать решение. Высококласные разработчики могут дать значительно лучшее решение, намного быстрее и дешевле. Великие проекты — удел великих разработчиков (Брукс).

Организация-разработчик должна добиваться следующего:

— Нанимать лучших разработчиков;

— Обеспечивать напрерывное обучение и повышать уровень образования своих разработчиков.

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

— Стимулировать разработчиков, устраняя препятствия и направляя их усилия на продуктивную работу.

— Создавать исключительно благоприятную рабочую атмосферу (зачастую это оказывается намного более важным, чем редкие прибавки к жалованью).

— Увязывать личные цели разработчиков со стратегией и задачами организации.

— Придавать особое значение коллективной работе. [33]