Русскоязычная документация (виды документов)




В теме 11 ответов, и 5 участников, последнее обновление сделано пользователем Аватар (Aliaksei Rudzko) Aliaksei Rudzko 14 г, 6 мес. назад.

Показано 12 ответов - от 1 до 12 (всего 12)
  • Автор
    Сообщения
  • 18.05.2010 в 15:10 # 5809
    Кто тесно работал с русскоязычными заказчиками и на русскоязычных проектах, поделитесь, пожауйста, знаниями, какие документы разрабатываются, как называются и хоть минимально, зачем они и что содержат. Если есть возможность, то приведите, пожалуйста, полный список, т.е. даже те, которые лично аналитик не разрабатывает..
    Поделиться:

    Цитировать

    20.05.2010 в 10:13 # 5810
    Аватар (Aliaksei Rudzko)
    Aliaksei Rudzko
    Подписчик
    Работал недавно с белорусским клиентом. Из документов поставили "Обзор" — полный аналог Vision и "Функциональную спецификацию" — аналог SRS.
    Поделиться:

    Цитировать

    20.05.2010 в 10:23 # 5811

    Работал недавно с белорусским клиентом. Из документов поставили "Обзор" — полный аналог Vision и "Функциональную спецификацию" — аналог SRS.

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

    Поделиться:

    Цитировать

    20.05.2010 в 17:55 # 5812
    Аватар (Aliaksei Rudzko)
    Aliaksei Rudzko
    Подписчик
    Заказчик не требовал придерживаться конкретных стандартов. Поэтому взяли Vision и SRS от внутреннего СаМовского проекта. Всё очень обычное. Вырезать конфиденциальную информацию не получится, т.к. специфика белорусского рынка для домена клиента предполагает жесткую конкуренцию и публиковать выдержки было бы "нечэсна". Походу проекта заказчик затребовал немало забавных изменениий формата SRS, что впрочем не привело к отходу от стандарта. Я на том проекте с dimon -ом работал. Так что можешь у него спросить подробности.
    Поделиться:

    Цитировать

    21.05.2010 в 13:43 # 5813
    Аватар (Sergey.Shimansky)
    Sergey.Shimansky
    Подписчик
    Как мне кажется, здесь многое зависит от Заказчика. Если это большая организация (да еще со своим отделом АСУ), то, скорее всего у них есть и какие-то правила к оформлению документации, которых вы должны будете придерживаться.

    Вот, что я могу сказать исходя из своего опыта.

    1. Государственные Заказчики.
    Насколько мне известно, гос. организации обязаны оформлять документацию согласно ГОСТ-34. По крайней мере один наш очень серьезный гос. Заказчик это требовал. С этим Заказчиком работали так:
    1. С начала было подготовлено Техническое Задание (что-то около 300 стр.). По нему выполнили определенный объем работ.
    2. Когда потребовалось вносить изменения в ТЗ и приступить к новому этапу работ, оформили все изменения/уточнения требований документами "Частное Техническое Задание". ЧТЗ имеют свою нумерацию и соответствуют определенному модулю (или функциональной области) разрабатываемой системы.

    Несмотря на то, что ГОСТ регламентирует структуру документа, внутри секций вы имеете достаточно свободы действий. Мы, например, взяли пункт «Требование к функциям (задачам), выполняемым системой» и внутри этого пункта расписали почти все требования в том порядке, как посчитали нужным.

    Вот ссылка на ГОСТы — http://www.rugost.com/index.php?option= … &Itemid=53м

    2. Негосударственные заказчики.
    Здесь, как правило, проще, т.к. вы можете использовать любой шаблон. Тем не менее, почти всегда последнее слово будет за Заказчиком. Поэтому если Заказчик требует ГОСТ (или внутренний шаблон) то будет сложно отвертеться :) .
    В моей компании изначально готовилось ТЗ в свободной форме, куда включали все требования. Все уточнения/изменения требований оформлялись оформлялись в виде отдельных документов , имеющих свою нумерацию в рамках проекта.

    Самое главное в работе с отечественными Заказчиками — убедитесь, что документ не только подписан, но и внимательно прочитан :wink:

    Поделиться:

    Цитировать

    28.05.2010 в 11:36 # 5814
    Аватар (Belle Morte)
    Belle Morte
    Участник
    Мне кажется есть один опасный момент по поводу использования документов вида Vision and Scope и SRS при работе с белорусскими клиентами. Даже если заказчик не требует следования ГОСТ: если в итоге он окажется недоволен проделанной работой (а повод придумать трудности особой не представляет) и дело дойдет до суда, исполнитель не сможет никак себя обезопасить. Проведение анализа, работа с требованиями — это такая услуга, которую проблематично "пощупать". И если заказчик в итоге скажет, что не получил никакого ТЗ, даже если была создана идеальная SRS: у нас в стране она не является действующим стандартом, и получится, что свои обязательства исполнитель по контракту не выполнил.
    Поделиться:

    Цитировать

    28.05.2010 в 14:03 # 5815
    Аватар (Yury L.)
    Yury L.
    Подписчик
    Ася…написала так, как будто у нас работала.
    Поделиться:

    Цитировать

    28.05.2010 в 15:13 # 5816
    Аватар (Sergey.Shimansky)
    Sergey.Shimansky
    Подписчик

    Мне кажется есть один опасный момент по поводу использования документов вида Vision and Scope и SRS при работе с белорусскими клиентами. Даже если заказчик не требует следования ГОСТ: если в итоге он окажется недоволен проделанной работой (а повод придумать трудности особой не представляет) и дело дойдет до суда, исполнитель не сможет никак себя обезопасить. Проведение анализа, работа с требованиями — это такая услуга, которую проблематично "пощупать". И если заказчик в итоге скажет, что не получил никакого ТЗ, даже если была создана идеальная SRS: у нас в стране она не является действующим стандартом, и получится, что свои обязательства исполнитель по контракту не выполнил.

    Согласен, у нас всегда все сложно ;) Это вопрос больше из практики управления проектами, нежеле анализа требований. Мне не очень понятна ситуация, описанная выше — Заказчик оказался недоволен проделланной работой по всему проекту или только по стадии анализа? Наверное, по всему проекту:)

    Такие риски обычно митигируются на стадии заключения контракта. Если это Fixed Price проект, то обычно к контракту уже прилагается детальный перечень артефактов, которые подрядчик предоставит Заказчику и требования к этим артефактом. Также можно обезопасится документом "План приемки" или "План ввода в эксплуатацию" который подписывается Заказчиком, чтобы потом вопросов не было. Как быть здесь с проектами T&M к сожалению не знаю.

    Мне доводилось готовить документ типа "Концепция ХХХ системы" — почти полный аналог Vision and Scope. Не помню, чтобы он сильно обезопасил риски доведения дела до суда. Мы дополнительно готовили список фич, которые будут разработаны и прикладывали к контракту. По-моему называлось это что-то типа "Функциональная спецификация".

    Поделиться:

    Цитировать

    28.05.2010 в 15:27 # 5817
    Аватар (Belle Morte)
    Belle Morte
    Участник

    Мне не очень понятна ситуация, описанная выше — Заказчик оказался недоволен проделланной работой по всему проекту или только по стадии анализа? Наверное, по всему проекту:)

    Честно говоря, я имела в виду только стадию анализа. Когда есть готовый проект, мне кажется, проще доказать, что работа выполнена. А вот анализ — это более абстрактное понятие, попробуй докажи, что он проведен, если для заказчика Use Case диаграмма — не более чем дурацкие кружочки.

    Поделиться:

    Цитировать

    28.05.2010 в 15:49 # 5818
    Аватар (Sergey.Shimansky)
    Sergey.Shimansky
    Подписчик
    Наверное, это скорее вопрос к юристам. Почти всегда в календарном плане-графике работ, который прилагается к договору, прописывается стадия сбора/анализа требований. Напротив этой стадии указывается срок исполнения. Ну и необходимо определять критерии выполнения задачи — подписанная документация.
    Честно, говоря, я никогда не слышал, чтобы Заказчик не подписывал хорошую документацию, в которой отражены его требования на понятном языке. Тем более что "кружочки" всегда воспринимаются на -ура:)

    P.S. Просто интересно — у вас был какой-то конкретный прецедент?

    Поделиться:

    Цитировать

    31.05.2010 в 10:46 # 5819
    Аватар (Belle Morte)
    Belle Morte
    Участник
    У меня лично конкретных прецедентов не было, но я пессимист ) Я знаю, что подобное, увы, случается, чаще всего это касается именно гос. огранизаций, которым получить результат работы хочется , а платить за него — не очень. Но вообще говоря это действительно вопрос к юристам.
    Поделиться:

    Цитировать

    02.06.2010 в 18:08 # 5820
    Аватар (Aliaksei Rudzko)
    Aliaksei Rudzko
    Подписчик
    Здесь очень важно что именно написано в договоре. И юристам на откуп отдавать этот нюанс нельзя. Юристы разбираются в тонкостях делопроизводства, но не знают ИТ стандартов.
    Правильный процесс. 1) Юрист берет название документа из первоначального предложения. 1.1) Если название не подходит с юридической точки зрения, то 1.1.1) обсуждает с аналитиками как можно документ переименовать, чтобы тот соответствовал юридическим требованиям или 1.1.2) требует переоценить проект/ отменитьпроект в связи с тем, что придется-таки делать документ соответствующий определенному стандарту.
    Неправильный процесс (тут мне стыдно за нашу компанию): 1) Юрист исправляет (посоветовавшись только с руководством) название документа. 2) Ближе к окончанию проекта аналитик узнает, что делает не то. :(
    Поделиться:

    Цитировать

Показано 12 ответов - от 1 до 12 (всего 12)

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