Создание языка и подхода, более или менее специализированного к какой-то предметной области -- крупное достижение. Поступая таким образом, авторы должны долгое время продумывать, как лучше всего управляться с проблемами, разделять их, исследовать их, смотреть на них с разных точек зрения и в соответствии с этим разрабатывать свой подход или язык. Но многое оказывается запутанным из-за пресловутого языкового барьера картостроитель/паковщик, и приходится отказываться от акцента на творческое мышление, необходимое для построения карты между проблемой и ее языком. Вместо того, чтобы представлять свой подход как структуру и предлагать некоторые эвристики для рассмотрения проблемы в терминах этой структуры, они вынуждены использовать процедурный язык и описывать действия, которые необходимо предпринять, императивно [строгим командным голосом - С.К.]. Если кто-то не обладает даром думать творчески,
С точки зрения многих инженеров-программистов, большая часть их жизни состоит в написании документов. С точки зрения настоящей работы, мы предпочли бы сказать, что их жизнь состоит в выполнении работы по повышению понимания, которое будет донесено до их коллег в соответствии с протоколом, определенным в их процессе. Следовательно, мы подразумеваем, что работа -- это всегда понимание, а процесс говорит, какое понимание нам нужно передать коллегам. Это определяет приемлемый для каждого документа язык. Эти соображения помогут сформировать описание реальной работы, которую требуется выполнить при работе над каждым из создаваемых инженером документов, как то: Требования Пользователя, Требования к Программному Обеспечению, Архитектурный Проект, Детальный Проект и Спецификация Тестирования (User Requirement, Software Requirement, Architectural Design, Detailed Design and Test Specification).
Следует отметить еще два момента. Во-первых, работа не заключается в создании кучи невразумительных бумажек, которые никто даже не будет читать, но которые по виду напоминают "конструкторскую документацию". Те, кто выплескивает технические подробности (все слеши и десятичные точки) в основном тексте, вместо того, чтобы поместить их в приложении, если уж это так нужно, просто издеваются над читателями и дискредитируют наше искусство в целом. Используя простой, нормальный язык (включая где необходимо специальную терминологию, но не злоупотребляя ею) расскажите читателю то, что ему нужно знать.
Второй момент касается формата. На любой стадии процесса программирования люди используют понимание, чтобы находить и предлагать паттерны. Если бы они знали, что они собираются найти, у них не было бы работы, поскольку их мог бы заменить настроенный кем-нибудь коммерческий (COTS) продукт. Раз мы не знаем наверняка, что работнику нужно представить, то как мы можем сказать ему, как он это должен представить? Стандартные форматы в процессах не должны восприниматься как догмы. Все приличные процессы в ISO 9001 содержат стандарты размещения необходимых разделов. Используй их соответственно, и если во время написания возникает структура документа, можно сделать вставку в План Управления Проектом, чтобы описать выбранный формат. Вот и вся суть ISO 9001.
Требования пользователя
Вильям Л Саймон , Вильям Саймон , Наталья Владимировна Макеева , Нора Робертс , Юрий Викторович Щербатых
Зарубежная компьютерная, околокомпьютерная литература / ОС и Сети, интернет / Короткие любовные романы / Психология / Прочая справочная литература / Образование и наука / Книги по IT / Словари и Энциклопедии