ГОСТ, IDEF, ... , Чем руководствоваться?

[Артем]

  День добрый!

На форуме много встречал слова "ТЗ", "технический проект", "спецификация", и т.д.

 А где-бы мне узнать значение этих слов (словарь Даля не предлагать ) и какие документы следует писать ДО того, как приступил к кодированию, а какие -- ПОСЛЕ?

 В ГОСТе я нашел чем "ТЗ" отличается от "тех. проекта" и как они должны выглядеть.

 НО, например, Альф, несколько раз ставил под сомнения пригодность вышеназванного документа, в качестве руководящего при написании программ.

 Читал про UML, но это (как отметил dimka) всего лишь язык, и вроде ничего мне не мешает использовать его вместо структурных схем описанных в ГОСТе.

Сам вопрос:
 Какие существуют стандарты?
 Чем они хороши/плохи?
 Есть ли эти стандарты в инете? (в свободном доступе)

                                   С уважением, Артем.


P.S.  Пишу систему сбора и обработки информации под винды....

[Dimka]

Какие существуют стандарты?

Я думаю, нужно следующее уточнение.

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

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

Твой вопрос наводит на мысль, что стандарта предприятия у тебя нет. Тогда возникает другой вопрос: тебе этот стандарт нужен для организации собственной работы или для поставки оформленного решения заказчику? Если стандарты нужны для заказчика, то интересоваться нужно у него, что ему нужно. Если стандарты нужны для себя, то необходимо сначала описать свою работу - как она организована, чтобы потом уже определяться, какие стандарты более подходят к привычному способу работы. В противном случае необходимо планировать реформирование рабочего процесса. Если планировать такое реформирование, нужно иметь набор определённых целей, которых реформа поможет достичь. Надеюсь, эти твои вопросы - не следствие "веяний моды", а объективная потребность.

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

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

И вот после этого введения можно уже переходить к предметному обсуждению методологий, методик и стандартов на их основе.

[Артем]

Твой вопрос наводит на мысль, что стандарта предприятия у тебя нет.

 Стандарта предприятия как такового нет. Есть некий стандарт дефакто (что-то вроде упрощенного ЕСПД).

  Тогда возникает другой вопрос: тебе этот стандарт нужен для организации собственной работы или для поставки оформленного решения заказчику?

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

 И вот передо мной стоит глобальный вопрос: Как сделать так, чтобы по прошествию времени, выделенного на завершение проекта, всё-таки завершить его (и не как-нибудь, а что-бы заказчик остался довольным ) ?

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

 НО (пока, только IMHO) даже если и не удасться убедит начальство следовать найденной (изобретенной) методики (стандарту), то, возможно, следования этой методики со стороны исполнителя уже даст шанс.


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

P.S. Для полноты картины:

 Коллектив исполнителей 2-3 человека.

 В нашем НИИ исторически сложилось так, что используется "чистый Си" (что не мешает "строить" проект на СОМ-объектах).

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





 

[Dimka]

В результате: у исполнителей одна картина (соответствует ТЗ), а у заказчика другая (тоже соответствует ТЗ ), различие этих "картин" видны в других документах, но они уже противоречивы в "мелочах"... которые, оказывается, вовсе не мелочи.

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

Учитывая чистый C, лучше думать о структурном проектировании: книжка о SADT была в библиотеке клуба. Можно описывать систему при помощи DFD, затем преобразуя диаграммы в спецификации модулей, описываемые картами Константайна или картами Джексона.

Если планируется активное использование COM, то можно подумать и об ООП. Но вот назвать какой-то конкретный метод объектно-ориентированного проектирования я не могу... так вспоминаю, и получается, что я читал самые разнообразные книжки на эту тему, и мои личные методы меняются в зависимости от задачи. Иногда ориентация идёт на данные, иногда на процессы...

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

Задача №2 - показать результат руководству (заказчику), оговорить требования, возможно, оптимизировать - что-то объединив, что-то исключив. Может быть чего-то нужно будет дополнить. На этом фиксируется цель проекта. Требования должны быть сформулированы таким образом, чтобы они не менялись как можно дольше. Если есть множество изменяющихся требований, нужно стараться выделить в этом множестве некий инвариант - тот фундамент, на который можно опереться. Обычно это достигается путём формулировки более общих утверждений, вмещающих в себя все изменения как несущественные частности. Однако эти обобщения должны в то же время иметь какой-то прагматический смысл, годный для определения архитектуры.

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

Задача №4 - выложить всё это руководству (заказчику), сказать, сколько времени и трудовых ресурсов потребует проект. Возможно, руководство решит что-то сократить. Затем оговорить каждое требование - расставить приоритеты: что должно быть реализовано обязательно, что желательно, а что оставить напоследок. Естественно, напоследок нельзя оставлять требования, которые влекут за собой масштабные переделки архитектуры - т.е. важные требования не могут иметь низкий приоритет.

Задача №5 - думать о реализации. Выбирать вариант архитектуры, наиболее подходящий для удовлетворения всех требований, под него более-менее точно оценивать трудоёмкость всех задач, составлять план решения задач (в том числе их последовательность или параллельность).

Задача №6 - реализация.

Задача №7 - тестирование и сдача в эксплуатацию.

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

Этапы 2-7 можно делать итерациями, если промежуточные результаты дадут имеющую самостоятельный смысл частично работающую систему.

Артем, у тебя на какой стадии сложности?

[Артем]

Артем, у тебя на какой стадии сложности?

 Если имеется ввиду: "на каком этапе?" тогда, скорее всего третий, причем первые два еще толком не закончены...
т.е. требования есть но они не "приведены в порядок" и с руководством эти требования обсуждены, но никакого документа после этого обсуждения нет.

 В том что необходима новая архитектура--ни у кого (уже) нет сомнений.

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

Что-то в этом роде я и ищу... я подумал, что надо сначала определиться со средствами, а потом переходить к решению.
 
сегодня посмотрю книжку про SADT.



P.S.
Использовать СОМ активно планируем (точнее "нас планируют"), но надо оставатьсь на чисто Си

[Dimka]

т.е. требования есть но они не "приведены в порядок" и с руководством эти требования обсуждены, но никакого документа после этого обсуждения нет.

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

[Артем]

   День добрый!

   Недавно состоялся разговор с начальством о методитке разработки ПО.
 Они настаивают на следовании ЕСПД, в частности, жизненный цикл предлагается строить на основе документа
"СТАДИИ РАЗРАБОТКИ" (см. прикрепление).   Я был бы благодарен за любые комментарии этого документа (как критеку, так и положительные отзывы).
 

[Dimka]

Знакомый документ

В целом ГОСТ ориентирован на программирование, а не на проектирование. Этапа анализа предметной области и составления информационной модели в нём просто нет. Разве что это попадает в пункт "Сбор исходных материалов". Из ряда пунктов разработки ТЗ вытекает необходимость к моменту подготовки ТЗ уже иметь готовый проект. А это абсурдно. Подготовленные документы должны помогать разработчикам в их работе, а они превращаются в бесмыссленную макулатуру.

ГОСТ предполагает, что программу можно написать за один приём. Понятия "поддержки" или "сопровождения" он вообще не предусматривает. Итерационной разработки, пробных внедрений и т.д. тоже нет. Учёта возможности изменения требований нет.

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

Если примечание

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

толковать особо вольно, то от ГОСТа ничего не останется.

Если уж твоё руководство так любит ГОСТы СССР, посмотри на том же сайте ГОСТы, посвящённые разработке АСУ http://linux.nist.ru/hr/doc/gost/gost24.htm. Может там найдётся что-то более подходящее для твоей задачи. Но сразу предупреждаю, что в плане оформления проектной документации это "тихий ужас".

P.S. Сказать так вот однозначно, что твой проект по этому ГОСТу сделать нельзя, я не могу - не знаю проекта. Однако полагаю, что велика вероятность того, что по этому ГОСТу вести разработку будет крайне неудобно.

[Артем]

Если примечание

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

  толковать особо вольно, то от ГОСТа ничего не останется.

похоже, что именно так и придется поступить.

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

Спасибо, dimka, за участие. В общих чертах, план действий у меня сформировался:
 1. побольше "выпросить" времени на проектирования.
 2. за это время попытаться освоить нотацию UML.
 3. идти примерно тем путем, что ты описал в своем посте "Август 14, 2006, 18:40:39".
 4. там где требуется описание структуры (взаимодействия, потоков данных...) попытаться использовать UML (в основном лишь для того, что бы не изобретать свои значки)

P.S.
 Если не забуду--через полгода-год напишу что получилось

[Dimka]

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

Хм... для процессов, хранилищ и потоков данных тогда уж лучше DFD - они по определению Data Flow Diagrams... - (+ ERD для собственно хранилищ), если речь о проекте программной системы, а не описания бизнес-процессов предприятия... Для последних Alf, к примеру, IDEF0 расхваливал.