Программирование >>  Реализация целостности данных 

1 ... 67 68 69 [ 70 ] 71 72 73 ... 124




Сотрудничество при проеровании

ГЛАВА

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

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

Общение с заказчиком

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

Если документ он предназначен для разработчиков, те потребуют

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

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

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



ЧАСТЬ 2 Проетрованйе ( ляьианнш систем бея дакнык

Каталованнй предназначен непосредственно для заказчиков. В нем содержится понимание требований к системе, по возможности, без технической терминологии.

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

В спецификации подробно описывают элементы системы и способы взаимодействия между ними.

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

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

Структура документа

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

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

структура более или менее соответствует структуре второй части этой книги. Разумеется, подобное совпадение не случайно.

Скорее всего, первый раздел вашего документа - введение.

Введение

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

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

Является ли выбранное решение оптимальным с точки зрения соотношения цена - качество ?

Какие альтернативные варианты рассматривались?

Каков планируемый срок выполнения проекта?



1 ... 67 68 69 [ 70 ] 71 72 73 ... 124

© 2006 - 2024 pmbk.ru. Генерация страницы: 0
При копировании материалов приветствуются ссылки.
Яндекс.Метрика