Привет всем!
Какой перечень документов получает заказчик от компании подрядчика на внедряемую систему?
Меня интересует перечень документов и их примерное содержание(по госту и тп).

Спасибо.

Андрей, а если посмотреть сами ГОСТы

Уже что-то нашел: http://www.rugost.com/
Однако интересует мнение более опытных товарищей. 

Концепция, ТЗ, ТП, Руководства пользователя и админа

Обычно, заказчик хочет получить как можно больше документов, а подрядчик - сделать как можно меньше. А так - как договорятся. Иногда удается отбиться одним Руководством оператора, а однажды как то даже делал Ведомость Держателей Подлинников (о-как!

В общем случае определяется договорными обязательствами.

Вы могли бы уточнить вопрос ?

Дмитрий.
Что тут уточнять?
Наша компания чтит: ITIL ,ISO9000.
Из доков что есть: руководство пользователя и все.
Видимо так хитро договор составили.Большая политика надо понимать.
Доступ к базе данных есть только у них.Мы можем только юзать и потребовать доработать то-то или что-то.

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

Суть в том.Если их компания рухнет ,то нам конец.
Поэтому руководство создать документацию о системе.
А мне интересен выше указанный вопрос.
И вообще реально что-то у них вытащить?

Какой перечень документов получает заказчик от компании подрядчика на внедряемую систему?
Меня интересует перечень документов и их примерное содержание(по госту и тп).

ГОСТ носит рекомендательный характер, его наличием никого не убедишь. Они Вам в ответ сразу скажут, что они работают по наиновейшим технологическим методологиям (super-extra-UMgile-concurrent-extreme-development), где требования ГОСТ по документированию не являются обязательными. И вообще это экспериментальный софт, НИОКР какой-нибудь, чего же Вы еще от нас хотите.
Думайте в направлении: Что является обязанностью поставщика по договору? Он ее выполнил?

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

А как формальными документами регламентируется право их доступа к Вашей базе? Или все не так и Вы у них право использования их БД приобрели? Или они Вам еще и услуги по управлению базой оказывают?

Поясните ситуацию.

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

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

Поэтому руководство ... создать документацию о системе.
А мне интересен выше указанный вопрос.
И вообще реально что-то у них вытащить?

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

Наша компания чтит: ITIL ,ISO9000.
Суть в том. Если их (поставщиков) компания рухнет ,то нам конец.

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

Кстати, Вам еще не конец. Этот риск нужно правильно обработать, разумеется, потратив некоторое немеряное количество денег. Самое время поставить вопрос об обеспечении снижения зависимости от поставщика. Я бы попытался играть на двух фронтах в этой ситуации: пытался бы договориться о документации, и начал бы дёргаться на тему приобретения/разработки аналогичного софта в другой более квалифицированной компании.

Суть в том.Если их компания рухнет ,то нам конец.
Поэтому руководство создать документацию о системе.
А мне интересен выше указанный вопрос.
И вообще реально что-то у них вытащить?

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

Все зависит от системы. Если программный комплекс достаточно объемный и сложный, то div зрит в корень - вряд ли удастся восстановить или поддерживать его по переданным вам бумажкам...
С другой стороны, что мешает вашим подрядчикам написать в документации откровенную ерунду, или предоставить только часть информации. Формально они свои обязательства выполнят...
В любом случае документацию запросить необходимо (в крайнем случае поможет в новой разработке):
1. Доступ к БД - обязательно, если у по договору вы являетесь собственником программы и базы, то никаких отказов с их стороны быть не должно (мы все передавали по первому требованию).
2. Структкру БД - логическую и физическую модель.
3. Любые документы, описывающий требования к системе - в зависимости от того, какие у них стандарты (пояснительные записки, постановки задач...).
4. Методики расчетов - если ваша система что-то считает
5. Спецификации на отчеты.
По поводу ГОСТов и стандартов - в погоне за формой можно потерять суть. В идеале лучше пусть дадут те документы, которые они сами используют в работе (если это вам удастся), а не делают что-то специально для вас - все может обратиться в формализм и отписки.

Забавно. Я тут представил, если бы у нас кто-то попросил структуру БД. Я бы тоже растерялся от такой просьбы. А все потому, что такой структуры никто никогда не видел )). Самому страшно...4 года программу пишем...

Нанять грамотную контору - вот хорошее решение.

П.С: Мои соболезнования...

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

Совершенно нормальная ситуация.
Когда есть возможность, то в договорах стараемся полностью вычищать все ссылки на ГОСТ (это мы как разработчики).
Выше было правильно сказано, что ссылаемся на "(super-extra-UMgile-concurrent-extreme-development)".
Всякая документация, которую нужно отдать заказчику -  затраты.

Теперь по сути.

Смотрим ТЗ и договор.

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

Если в ТЗ документации нет, то возможны варианты:
1) Дозаказать документацию за отдельные деньги (надо понимать, что разработчик зафиксировал свою прибыль и в минус идти не будет ни при каких условиях). Если сумма вменяемая - это лучший вариант.
2) Если идет этап сопровождения, по отдельным ежегодным договорам, то в очередной договор можно включить и поставку доки. Суть - шантаж - нет доки, нет сопровождения. Шансы есть, но все зависит от ситуации (у кого нервы крепче).

Если удалость договориться о доработке доки, то не забудьте определить критерии качества затребованных документов. Просто перечень документов  и ссылка на ГОСТ – МАЛО, нужно раскрыть, что и в каком виде должно быть в каждом пункте.


Просто для справки.
Во вложении некоторая сводная таблица по составу ГОСТовых документов, которые передаются заказчику по окончанию разработки(минимум и максимум).

Кратенько состав документов на этапе разработки излагается в РД 50-34.698-90.

У нас одни клиенты долго требовали описание БД. Когда получили, первым делом полезли ковыряться в ней ручками, уронили систему, а мы потом двое суток восстанавливали, пытаясь понять, что же они сделали (они, естественно, не сознавались ни в чём).

Так что в некоторых случаях, отсутствие документации - благо.

Вы видели схему своего мобильного телефона принципиальную электрическую? А вот компания Siemens, к примеру, больше не выпускает мобильники (не то, чтобы она накрылась медным тазом, но проблемы у неё были серьёзные). Как же быть? А никак... Можно прозвонить плату самому, можно купить Нокию,с которой, кстати, тоже нет схемы в комплекте поставки. А вот в комплект цветного (!) телевизора Рубин схема входила в своё время.