Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Shur

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 »
46
Не влезло в предыдущий

Ну и в конце, я поступлю как студент. Скажите правильно ли или лучше не так, понятно ли то, что тут изображено UCDPN5? Предлагаю когда будет время, опубликовать ваши описания по диаграмме, как вы ее воспринимаете. Потом сравним...

Можно рассмотреть диаграмму с нормативной точки зрения (соотнести с логикой спецификации) -1,  и с точки зрения описываемого диаграммой бизнеса -2.
1. Согласно спецификации "A use case is the specification of a set of actions performed by a system, which yields an observable result that is, typically, of value for one or more actors or other stakeholders of the system." ВИ на предложенной диаграмме представляются несколько фрагментарными. Может быть стоило сгруппировать действия учасников в меньшее количество более общих ВИ - например, "Заказ товара", "Оплата товара", "Доставка(поставка) товара"? ИМХО на диаграмме ВИ не стоит пытаться детально описать логику действий, которые подразумевает конкретный ВИ. Детальное описание действий, составляющих ВИ, можно раскрыть в диаграмме(ах) деятельности. В идеале: для каждого ВИ - по диаграмме. Причем после рисования диаграмм деятельности вернуться к ДВИ и поправить её, если нужно. Не стоит пытаться ответить в ДВИ сразу на все вопросы. Лучше если разные диаграммы будут дополнять и уточнять друг друга. Поскольку ВИ должны определять множество действий, лучше если название ВИ будет отражать множественность действий, которые необходимы для его выполнения - т.е. предлагаю не называть ВИ так, чтобы его можно было принять за единичное действие, если на самом деле он подразумевает целый бизнес-процесс.
2. Насколько я понял из ДВИ, на ней представлен бизнес, типа интернет-магазина, связанный с доставкой товара по заказу клиента с оплатой товара через банк. Но ИМХО в представленном виде ДВИ представляет скорее взгляд покупателя, чем продавца. Покупатель не всегда видит, что важная часть работы продавца может быть вынужденно не связана непосредственно с работой с покупателем. Возможность продажи товара представленным на диаграмме образом на регулярной основе, как правило, требует участия других действующих лиц (ролей), помимо приведенных на ДВИ. В частности, лиц, осуществляющих доставку товара потребителю (поскольку для подтверждения получения товара на диаграмме предусмотрен целый ВИ, самовывоз не предполагается в качестве основного варианта?). У продавца должен быть предусмотрен ВИ для управления доставкой товара с участием этого ДЛ (курьер?, транспортная компания?). Также необходимо организовывать поставку товара к продавцу извне, для чего у продавца тоже должны быть свои ВИ, связанные с заказом и доставкой товара от поставщика или со склада магазина. Возможно. взаимодействовать с поставщиком товара должно другое ДЛ, но оно должно координировать поставки товара с продавцом. Еще должно быть лицо, осуществляющее учет операций. Возможно с этим управится бухгалтер, но если управление товарными запасами развернется в целое направление деятельности, он, наверное, будет возражать и настаивать на появлении ещё одно роли. Возможно, с точки зрения представленного на диаграмме бизнеса стоит ДВИ дополнить еще некоторыми ролями и ВИ.

47
Английский язык велик и могуч. И не всегда можно его понять буквально.
Цитата имеет разрыв и отсюда лингвистическую несолгасованность.
Если в первом предложении subject явно имеет смысл СИСТЕМЫ, ОБЪЕКТА, то во втором предложении использование этих определений спотыкается. Система (объект) варианта использования? - звучит очень не по-русски. ПРЕДМЕТОМ варианта использования, то же не вполне, но ближе. Но вполне по-русски будет перевод ОБЛАСТЬЮ ДЕЙСТВИЯ варианта использования.
Т.е. первое предложение будет звучать:
Каждый вариант использования точно определяет (обуславливает, устанавливает) некоторое поведение, возможно включая варианты, которое эта система (этот объект - т.е. нечто уже известное нам, ранее оговоренное, упоминаемое и определенное - определенный артикль the) может (а я бы лучше перевёл умеет!) выполнять в сотрудничестве с одним или более акторов.

Опять же не сотрудничество одного или нескольких акторов между собой, а сотрудничество система - самой являющейся особым выделенным действующим лицом и другими ВНЕШНИМИ по отношению к ней ДЛ.
Варианты использования могут применяться как (и) для точного определения (внешних) требований к объекту(предмету) (вообще), так и (и) для точного определения функциональности, предлагаемой объектом (предметом). Кроме того, ВИ также устанавливают требования (тут явно что-то пропущено. союз, запятая, предлог), которые указанный объект (предмет) ставит перед своим окружением, определяя, как они (интересно кто эти они?) должны взаимодействовать с (этим) объектом (предметом), чтобы он (этот самый объект) был в состоянии выполнить взятые на себя обязательства (свои сервисы-услуги)

Вот как тут после этого друг друга понимать :)

Sorry, если я Вас запутал.
*Если трактовать спецификацию так, настаивает Денис, то обе цитаты описывают поведение компьютерной системы с внешними по отношению к системе ДЛ. Некоторая проблема возникает, если компьютерной системы еще нет, но об этом ниже...
**Во второй цитате, ВИ взаимодействуют с субъектом-системой и на характер этого взаимодействия (поведения) ВИ накладывают требования (своим существованием).

В спецификации в разделе Notation для ВИ сказано - что
"A use case is shown as an ellipse, either containing the name of the use case or with the name of the use case placed below the ellipse. An optional stereotype keyword may be placed above the name and a list of properties included below the name. If a subject (or system boundary) is displayed, the use case ellipse is visually located inside the system boundary rectangle. Note that this does not necessarily mean that the subject classifier owns the contained use cases, but merely that the use case applies to that classifier."
Из спецификации следует, что система-субъект не обладает ВИ. ВИ просто применяются к системе-субъекту!ИМХО это снимает кажушуюся "кривизну" формулировки цитаты про environment из спецификации.

Т.е. в самой спецификации противоречий (во всяком, случае, вопиющих:) не видно. ИМХО разлчие мнений о полезности или способах использования ДВИ имеет очень косвенное отношение к вопросу о точности опсания ВИ и ДВИ в спецификации. Но имеет непосредственное отношение к вопросу применения ДВИ на практике. Причем применения ДВИ для описания не собственно компьютерной системы (она может даже не существовать на момент анализа бизнес и рисования ДВИ), а для описания деятельности, которую еще только предстоит автоматизировать. Я предложил трактовку спецификации, которая устраняет необходимость рисования диаграммы про то, чего еще нет. И трактовать ДВИ как диаграмму описывающую вазимодейсстве ДЛ с системой действующих лиц. Систему, представляющую собой предприятие заказчика, логику его работы, значимую для реализации системы.  Видимо, не случайно процитированная Денисом точка зрения Г.Буча в коллективном труде отцов-основателей - Г. Буч, Д. Рамбо, А. Джекобсон Язык UML Руководство пользователя" звучит в виде:
"Унифицированный язык моделирования (Unified Modeling Language, UML) является графическим языком для визуализации, специфицирования, конструирования и документирования систем, в которых большая роль принадлежит, программному обеспечению." Т.е. большая роль принадлежит ПО, но им не исчерпывается.

48
Согласен, что авторы спецификации предполагали использования понятия субъект прежде всего в качестве системы компьютерной, но явного запрета на интерпретацию системы как сообщества взаимодействующих для достижения некоторых целей по определенным правилом лиц спецификация ИМХО не содержит.   Я не буду настаивать на том, что спецификация ДВИ в  UML предназначена именно для описания взаимодействия пользователей с участием системы. Я писал о возможности такой интерпретации ДВИ. Система-субъект - посредник, которая взаимодействиует с ДЛ, причем, возможно с несколькими. Сам факт такого множественного участия ДЛ в ВИ представляется важным и, как правило, означает необходимость координации действий этих ДЛ при осуществлении ВИ.  Увидеть на ДВИ кто какие работы выполняет, с кем нужно обсуждать требования к отдельным видам работ (ВИ), на этапе анализа бизнеса заказчика ИМХО весьма полезно. Для этого можно использовать ДВИ. Можно, конечно, интерпретировать  все утверждения спецификации в смысле "что не разрешено явно, то запрещено". И не использовать ДВИ предложенным мной образом.

49
ДИ не предназначена для того, чтобы описывать "взаимодействия действующих лиц с другими действующими лицами (не обязательно с системой) ". Стандартом UML определено единственное возможное отношение между ДЛ - обобщение, которое нужно для уменьшения количества ассоциация между ДЛ и ВИ на диаграмме.

Это не та задача, которую должна решать ДИ

Это не так - см . (OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2, N o v e m b e r 2 0 0 7 )
 
16.3.6 UseCase (from UseCases)

Each use case specifies some behavior, possibly including variants, that the subject can perform in collaboration with one or more actors...The subject of a use case could be a physical system or any other element that may have behavior, such as a component, subsystem, or class. ...

Т.е. cубъект ВИ - экземпляр класса ДЛ может обладать поведением, которое он может осуществлять во взаимодействии с другими ДЛ.

Use cases can be used both for specification of the (external) requirements on a subject and for the specification of the
functionality offered by a subject. Moreover, the use cases also state the requirements the specified subject poses on its environment by defining how they should interact with the subject so that it will be able to perform its services.

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

50
6. Обе диаграммы ориентированы на отображение взаимодействия внешних сущностей с системой

Вообще говоря, с помощью ДВИ можно изобразить взаимодействие действующих лиц (ДВИ), задействованных в некоторую совместную деятельность. Сама эта деятельность носит системный характер, поэтому и лица и ВИ в широком смысле являются частью некоей системы (не в смысле некоего программно-аппартного комплекса).  Нарисовать границу системы (рамку), как указывал выше Boatman важно, особенно если необходимо выделить границы автоматизируемой деятельности, но иногда и без этой рамки картинка взаимодействия действующих лиц с другими действующими лицами (не обязательно с системой) через ВИ помогает понять бизнес Заказчика. Особенно если мы хотим прояснить топологию взаимодействия лиц.

7. ДВИ специфицируется через описания ВИ, DFD через миниспецификации процессов. Хотя в последнем случае упор на функциональное деление.

ИМХО содержание ВИ, указанных на ДВИ,  можно детализировать диаграммами деятельности. Особенно на этапе анализа, выявления логики бизнеса Заказчика, безотносительно к возможным программно-аппаратным решениям по его автоматизации. Можно конечно привлекать и диаграммы последовательности, состояний но они сразу тянут за собой диаграмму классов, а это ИМХО  затрагивает компетенцию архитектора и эти диаграммы хорошо бы рисовать минимум вдвоем - бизнес-аналитик и архитектор.


Какие трудности я вижу при создании ДВИ, что потом влечет за собой и трудности в описании ВИ.
1. Понятие цели пользователя - что же считать целью пользователя, можно ли использовать текстовый шаблон, какой он будет, какие критерии позволяют сказать - это цель, а вот это не цель. Что же понимают англичание под словом цель: purpose, aim, objective, target, goal, intent, intention...
возможные ответы:
  - то, что может считаться элементарным бизнес-процессом, определенной обязанностью сотрудника
  - то, что одобряется руководством как исполнения полезной работы
  - нечто краткое, сеансовое, законченное - транзакция

2. Наименование варианта использования - с какой стороны стоять при именовании ВИ (это к тому регистрация покупки или регистрация продажи). Если имя ВИ - цель, должное ли оно отржать SMARTER конфигурацию, обязательно выраждаться в ответ ДА-НЕТ.

ВИ на ДВИ допускает участие в ВИ нескольких пользователей, преследующих разные цели, поэтому пытаться выносить цели пользователей в название ВИ (на ДВИ) - очень сильное, не всегда реализуемое требование.

3. структурирование диаграммы -не понимание связей обобщение, зависимостей include и extend. Не следует ли на этапе анализа заменить их, следуя, Розенбергу на invoke и precede. Первое как либо include или extend (конкретная реализации смысла будет потом на стадии проектирования), а второе без аналогов, просто демонстрирует некое предшествование, то что должно быть выполнено в начале, но имеет и самостоятельно значение? А то и вовсе запретить структурирование ВИ, разрешив только структурирование акторов, как наиболее понятное и очевидное?
4. выделение акторов

ИМХО некорректно пытаться отразить на ДВИ последовательность осуществления ВИ, что неизбежно возникает при попытке отразить на ДВИ отношения invoke и precede. Как отразить условия осуществления, ветвления последовательности осуществления ВИ при выполнении invoke и precede?  Не лучше ли тогда просто нарисовать диаграмму(ы) деятельности?

51
Претензии в приведенном примере относятся к тому,
1. как именно была использована (нарисована) ДВИ или
2. к самой спецификации ДВИ?

Если 1, то, может быть стоит взять менее "игрушечные" примеры (например ДВИ из Universal Business Language 2.0 Public Review Draft)? А то всякие примеры с наливанием чашки кофе или чая, честно говоря, достали. Можно подумать, что именно автоматизация наливания кофе в чашку является для ИТ такой же фундаментальной проблемой, какой была теорема Ферма для развития математики. Для таких "мелких" задач ДВИ точно бесполезна.
ИМХО, значение ДВИ для проекта определяется возможными вариантами этой диаграммы, из которых нужно сделать одну по результатам обсуждения с Заказчиком (а то и в результате объединенмя несколькмх диаграмм по результатам обсуждения с разными представитлеями Заказчика). Поэтому рассматривать диаграммы в отрыве от конкретной ситуации, различных пониманий бизнеса Заказчика, которые должны быть приведены к "общему знаменателю", весьма затруднительно. А без общего (для участников обсуждения) бизнес-контекста вряд ли удастся к этому знаменателю приблизиться.
Кстати, истина рождается в обсуждении, в споре она умирает :).


52
Ладно хорошо - вернусь как прочитаю книгу Коберна. Если успею. Спасибо всем за помощь :)

1. Каждый ВИ на диаграмме, согласно спецификации UML 2, должен подразумевать набор действий - в вашем же случае каждый ВИ на самой первой диаграмме содержит фактически одно действие (кроме, возможно, того, что Вы назвали "формирование отчетности"). На других диаграммах Вы также использовали слишком "мелкие" действия пользователей системы в качестве элементов ДВИ. Если Ваш бизнес действительно так прост, то Денис прав - ДВИ вряд ли будет полезна.
2. Вы сами написали в первом посте, что описали диаграмму деятельности - нарисуйте её. Еще диаграммы состояний для упомянутых Вами документов.Возможно, стоит уточнить на диаграмме деятельности (а возможно, и состояний) про технический паспорт вашего ОС - откуда он взялся и куда делся- на учет его берете или выбрасываете после испытаний?. Проанализируйте действия, в результате которых изменяются состояния документов. Поправьте по результатам этого анализа диаграмму деятельности, если нужно.
 3. Если диаграмма деятельности получится достаточно большой, можно попробовать разделить её на несколько диаграмм. Если получится, каждая диаграмма будет соответствовать ВИ.Теперь можете нарисовать ДВИ.Если, конечно, Коберн еще не убедил Вас, что рисование диаграмм - пустая трата времени :).

53
Опытная эксплуатация должна быть предусмотрена как этап работ в договоре. Чтобы сдать систему в опытную эксплуатацию (по ГОСТ) нужно провести предварительные испытания. На ней как раз и пишется акт приемки в опытную эксплуатацию.

Возможны варианты:
1. опытная эксплуатация на тестовых данных . Клиент в этом случае обязан предоставить такие данные.
2. опытная эксплуатация на "боевых" (почти промышленная эксплуатация).

Опытная эксплуатация может проводиться на тестовом оборудовании, отличающемся от того, на котором будет промышленно эксплуатироваться система. Это может иметь как плюсы, так и минусы, как для разработчика, так и клиента. Важно просто обратить внимание (свое и контрагента) на это заранее, на случай, если придется что-то дополнительно устанавливать/настраивать.

Клиент отвечает за своевременную фиксацию выявленных отклонений от Технического задания (ошибки реализации) в журнале опытной эксплуатации. Разработчик - за своевременное устранения выявленных отклонений/ошибок. Можно предусмотреть фиксацию устранения проблем прямо в этом же журнале. С таким документом и комиссии ставить подпись под актом о приемке в промышленную эксплуатацию не так страшно :).

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

54
Системный анализ изучать - интересно. Но может быть полезнее  пытаться обобщать практики решений для конкретных видов бизнеса? Возможно, даже, вдохновляясь этим самым системным анализом :)...

55
Да, но если отсутствует эта часть, то есть ли аналитик? :)

Вообще, какой Путь аналитика представляется более правильным - обучить эксперта предметной области некоей "теории анализа" либо мол. специалиста, владеющего этой теорией, погрузить в предметную область?

Практики, мне кажется, будут больше голосовать за первый путь (возможно, потому что сами по нему идут). Проблема лично для меня, например, в том, что я не вижу пока ясно очерченной "теории анализа", применимой в любой предметной области.

Вряд ли можно вырастить аналитика без взаимодействия этого аналитика с разработчиками. Это более важно, чем выбор специалиста с опытом или просто мол. специалиста с образованием. Важно, чтобы кандидат в аналитики мог формализовывать практическую деятельность в виде, понятном для разработчика. Это редкость. В строительстве есть такой документ - проект производства работ (ППР). По сути - это вылитое описание ВИ! Но специалисты, способных написать такой документ - большая редкость. Соответственно, большинство отечественных строительных проектов обходятся без этого документа.
ИМХО наиболее ценна работа аналитика если необходимо разрешать противоречия в требованиях от разных специалистов заказчика (разных специализаций). Эта работа иногда занимает достаточно много времени. Проблема в том, что она мало заметна для разработчика. Он получает готовое описание и недоумевает, а как вообще можно было сделать иначе? Чего столько копались-то?

56
Лично мне кажется, что пока слишком расплывчата основа для объединения и каких-то формальных мероприятий. Надо эту основу как-то кристаллизовать.

Эдуард, кстати, по резальтатам своей "летней практики" выразил почти дословно ту же мысль (сразу признаю, что мысль спорная), которая была высказана на встрече: "аналитик" может существовать только в конкретной предметной области. Абстрактных "аналитиков" без опыта работы в какой-то области не бывает.

Важно различать аналитика и "эксперта". Фактически (по жизни) есть две точки зрения на роли эксперта и аналитика:
1. Есть конкретные знания в предметной области (например, бухгалтерия), которые универсальны для всех видов бизнеса и регионов (т.е. бухгалтерия по большому счету везде одинакова - хоть в Москве, хоть в Иванове). Достаточно найти толкового эксперта, который внятно скажет как это все должно работать, то все что скажет эксперт может понять любой здравомыслящий разработчик и быстренько закодировать (а то, может и сам сообразит как и что, если эксперт не сильно продвинутый).

2. Могут существовать разновидности форм деятельности в рамках одной предметной области. Даже бухгалтерский учет может быть организован по разному в разных компаниях. Поэтому необходимо уметь адаптировать схемы учета или, шире, регулярные формы ведения бизнеса к конкретной ситуации, конкретного Заказчика. Без знания некоторого типового набора схем организации бизнеса такое конструирование выполнить невозможно. С одной  стороны - это схемы бизнеса, схемы из предметной области. С другой стороны эти бизнес-схемы можно укладывать в нотации и формы представления для описания бизнес-уровня, используемые при проектирования информационной системы. На стыке представлений ИТ и представлений бизнеса можно выявлять некоторые фундаментальные схемы устройства бизнеса. Эти "интерфейсные" представления на стыке бизнеса и ИТ и являются темой и инструментом для анализа. Это и не "чисто" бизнес-анализ и не совсем проектирование ИТ-системы. Особенно важно иметь такие представления, если необходимо "стыковать" разные предметные специализации, например, логистику и бухгалтерию (держа в уме что все это еще нужно будет "стыковать" с ИТ!). Искать эксперта по обоим областям в одном лице? Или вырабатывать/использовать интерфейсные представления между различными областями предметной деяетельности?

P.S. Пока писал bas запостил цитату с которой нельзя не согласиться с одним важным уточнением: инструментарий аналитика должен включать не просто "anlysis models" из области ИТ. Чтобы заполнять "knowledge gaps" желательно иметь некий инструментарий ("интерфейсные" представления не совсем в ИТ-смысле), помимо хорошо подвешенного языка и готовности услышать эксперта и Заказчика. Акцентирование знакомства с "best prctices" возвращают нас к позиции описанной выше в п.1. ("одноразовый аналитик").

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

ИМХО можно сформулировать следующие тезисы:
1. Начальству (и Заказчику) нужен продукт (качество, свойства продукта - самые верхнеуровневые требования).
2. Разработчикам нужны еще требования к процессу которые получаются декомпозицией верхнеуровневых требований. Архитектурные решения (и форму их представления) ИМХО важны для разработчиков. Если архитектор фактически руководит процессом разработки, по идее, проблем не должно быть. Например, когда в процессе разработки реально нужно принимать решения, делать выбор. Хуже если разработчики неявно оспаривают авторитет архитектора и рассматривают его просто как "описателя проекта".
3. Помимо нацеленности Заказчика на результат, в пользу общего описания требований в В официальных документах может быть следующий аргумент: существующая отечественная договорная практика "заточена" под "водопад". И итерировать всю иерархию требований в официальных документах (ТЗ для договора) сложно. Но иметь детальное описание требований конечно же нужно, особенно если  разработка ведется коллективом и если тестирование выделено в специализированный вид работ в компании.

58
К сожалению, опыта написания ТЗ у меня еще немного. Но я думал, что в документе ТЗ необходимо писать Детальные требования (из иерархии Бизнес-требования -> Требования пользователей -> UseCase'ы -> Детальные требования).

Я что-то не совсем правильно понял?

Избыточно детальные требования фактически содержат описание конкретных решений по реализации системы. При обсуждении Заказчик не может представлять себе всех деталей реализации, да они ему и не нужны. Как правило, ему важно, чтобы система, как черный ящик, выполняла необходимые ему функции. ИМХО детализация требований в ТЗ необходима, как правило, уже для согласованной работы разработчиков. Детализировать ТЗ до этого уровня приходится, если ИТ-специалисты со стороны заказчика настолько плотно опекают процесс разработки, что становятся фактически соисполнителями разработки (тяжелый случай :).  А обычно детализация требуется для конкретизации задач  для разработчиков, обеспечения согласованной работы внутри команды Исполнителя. Универсальные критерии - до какого уровня нужно детализировать, сформулировать сложно, но то, что не стоит детализировать все "до гаек" уже в ТЗ, стоит иметь в виду. Нужно обсуждать с Заказчиком, что ему нужно, оценивать ("в уме") возможность реализации, но конкретные решения без нужды ИМХО выкладывать в ТЗ необязательно. Может быть, добавить Приложения с оговоркой что, то, что в нем содержится, поясняет возможные пути реализации, но может быть изменено Исполнителем (!) при проектировании системы.

59
Да, я понимаю, что функции в этом разделе описывать надо обязательно. Вопрос как раз был в том, можно ли в этот же раздел "прикрутить" ВИ. Вы "прикручивали"? :) Успешно? :)

Дословно-нет. Чем меньше напишете в требования к функциям в ТЗ для договора - тем лучше для Вас, как Исполнителя. Описания ВИ (текстовые - не диаграммы ВИ UML), как правило, весьма подробны. По описаниям ВИ в принципе можно составить перечень функций  с их общим описанием (существенно менее детальном, чем описание ВИ). А детали (как бизнес, так и системного уровня), которые Вам скорее всего придется уточнять на этапе реализации, лучше не "прибивать гвоздями" сразу на этапе ТЗ.  Лучше показать их Заказчику, обсудить, но оставлять за собой возможность их изменения при реализации на этапе ЭП и ТП. Собственно, как и предусмотрено ГОСТ.

60

И вопрос - можно ли в ТЗ описывать ВИ? И если можно, то в какой части? Или может быть стоит вынести их описание в отдельный документ(ы)?


1. ГОСТ не запрещает описывать ВИ в ТЗ . Но описание требований к функциям в разделе 2.6.2 должно быть. Если заменить описание функций описанием ВИ - Заказчик будет иметь право возражать :).
2. Результаты оценки оформляются в виде отчета о выполненной работе (предпроектном обследовании). Есть ГОСТ на НИР, но он регламентирует фактически только форму титульного листа отчета.
3. В каком документе писать сколько денег будет стоить само обследование  вам ГОСТ ничего не скажет. Вообще-то странно, если Заказчик согласится Вам оплатить предпроектное обследование только для того, чтобы Вы заявили ему стоимость Ваших услуг. Особенно если он собирается оплачивать Ваши услуги из государственных средств. ИМХО больше шансов заключать договор сразу на составление ТЗ - и состав работ виден и стоимость видно к чему приложить. Все равно ТЗ будете писать на основании предпроектного обследования. Второй раз те же результаты обследования описывать, только в другом виде...

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 »