Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 21
Вы исходите из того, что ГОСТ (и вообще подзаконная нормативка) — это такая библия, которую все должны знать и на которую все должны опираться. И если даже для госухи это так (хотя даже там это не совсем так), то в других областях разработки это может быть совсем не так.
Отнюдь не обожествляю ГОСТы, особенно ГОСТ Р, но опыт доказывает, что соответствие чего-либо требованиям ГОСТов есть хотя бы минимальный показатель качества этого чего-либо. Все прочее — отсебятина, и останется ей до тех пор, пока не не станет стандартизованной отсебятиной :)
И, поверьте, никому ничего не навязываю. Пусть каждый учится на своих ошибках, если не умеет на чужих :)
И, поверьте, никому ничего не навязываю. Пусть каждый учится на своих ошибках, если не умеет на чужих :)
соответствие чего-либо требованиям ГОСТов есть хотя бы минимальный показатель качества этого чего-либо
Вот этого я как раз и не люблю. За последние несколько лет я видел сильно больше одного ТЗ, которые соответствовали ГОСТам, но были совершенно неприменимы как ТЗ. Очень расстраивает.
«Минимальный» — не значит «достаточный».
Уважаемый, если есть желание подискутировать — пишите конкретику, поскольку эмоциональных и безосновательных высказываний в рунете и без того выше крыши. Все это мало кому интересно. Как и то, что Вы любите или нет, что Вас расстраивает или нет.
Опубликуйте хотя бы одно из «сильно больше» такого ТЗ — обсудим, проверим на соответствие требованиям ГОСТов, найдем «неприменимости», в которых «виноваты» ГОСТы. А еще лучше — изложите свои понятия в части «достаточности» технических заданий, разработанных вне рамок ГОСТов, отдельной статьей. Тогда и пообщаемся, а флуд интереса не представляет.
Опубликуйте хотя бы одно из «сильно больше» такого ТЗ — обсудим, проверим на соответствие требованиям ГОСТов, найдем «неприменимости», в которых «виноваты» ГОСТы. А еще лучше — изложите свои понятия в части «достаточности» технических заданий, разработанных вне рамок ГОСТов, отдельной статьей. Тогда и пообщаемся, а флуд интереса не представляет.
«добейСЯ» = «добей СЕБЯ». Ап стену.
Возможно Вы не в курсе, но «добейся» — это повелительное наклонение слова «добиваться».
По моему, это повелительное наклонение слова «добиться», которое, в свою очередь, произошло от слова «бить».
При этом «до-бить-ся» — возвратный глагол. Значение возвратного глагола: «собственно возвратное — действие производится субъектом, к-рый является одновременно и объектом действия: умываться, одеваться, купаться». Или, иными словами, «ся» == «себя», в случае с возвратным глаголом.
Вы были правы, указав на то, что исходное слово производное от другого слова, но ничего не доказали и не опровергли по сути.
Вы были правы, указав на то, что исходное слово производное от другого слова, но ничего не доказали и не опровергли по сути.
Вы не в курсе того, что, хотя "-ся" в возвратных глаголах и происходит от «себя», оно далеко не всегда это обозначает? И между возвратным и невозвратным глаголами вообще может не быть семантической связи?
В курсе. Поэтому написал, что это в случае с «добиться». Вы, вообще, не о том говорите.
В таком случае предлагаю Вам самому «добиться».
Можете быть вольны вложить в это слово наиболее приемлемый для Вас смысл.
Можете быть вольны вложить в это слово наиболее приемлемый для Вас смысл.
Возможно, Вы не в курсе, но «СЯ» в старославянском всегда обозначало «СЕБЯ».
Если рассматривать идеальный случай: адекватный Заказчик и адекватный Исполнитель, заинтересованные в реализации проекта, то формула (читай последовательность) может быть такой:
1. Документ «Технические требования» — пишутся Заказчиком. Отвечает на вопрос: «чего хотим и ждем?»
2. Документ «Техническое задание» — пишется Исполнителем. Отвечает на вопрос: «чего будем делать, чтобы реализовать требования?»
3. Документ «Техпроект» (пояснительная записка к Техпроекту) — пишется Исполнителем. Отвечает на вопрос: «Что мы в итоге сделали?»
К сожалению, эта формула работает только в идеальном мире. Ведь шаги 2 и 3 идут, обычно, уже после заключения договора. Часто, не имея возможности заранее оценить Исполнителя, Заказчик пытается максимально обезопасить себя. Т.е. берет разработку ТЗ в свои руки, чтобы ТЗ шло приложением к договору. Дальше уже начинает изворачиваться Исполнитель. В результате получаем кашу, монструозные ТЗ, затягивание проектов и прочие радости.
1. Документ «Технические требования» — пишутся Заказчиком. Отвечает на вопрос: «чего хотим и ждем?»
2. Документ «Техническое задание» — пишется Исполнителем. Отвечает на вопрос: «чего будем делать, чтобы реализовать требования?»
3. Документ «Техпроект» (пояснительная записка к Техпроекту) — пишется Исполнителем. Отвечает на вопрос: «Что мы в итоге сделали?»
К сожалению, эта формула работает только в идеальном мире. Ведь шаги 2 и 3 идут, обычно, уже после заключения договора. Часто, не имея возможности заранее оценить Исполнителя, Заказчик пытается максимально обезопасить себя. Т.е. берет разработку ТЗ в свои руки, чтобы ТЗ шло приложением к договору. Дальше уже начинает изворачиваться Исполнитель. В результате получаем кашу, монструозные ТЗ, затягивание проектов и прочие радости.
Спасибо, Артем — это совсем другое дело, а то все флуд да эмоции, а потом еще и в «минуса» меня. Дурная манера пытаться пройти по чужим головам.
При полном адеквате схема приблизительно такая и есть. Правда, от самого заказчика хрен чего дождешься, особенно от подчиненных его, которым ни до чего нет дела. Вот и пришлось однажды объезжать все объекты Оренбурггазпрома и буквально насильно заставлять древних теток заполнять непонятные им опросные листы, чтобы хоть какие-то требования заказчика поиметь.
С ТЗ несколько иначе — оно не отвечает на вопросы, а только является перечнем требований как к функционалу, так и ко всему прочему. А на вопросы уже отвечают документы, разрабатываемые на стадии «Технический проект». Если руководствоваться ГОСТами 34-й системы, то их там дофига и больше. А для подведения итогов разрабатывается Программа и методика испытаний, по которой испытания и проводятся, по результатам испытаний составляется Акт приемки сдачи и им работа завершается. Это так, все на пальцах, в жизни сложнее бывает.
ТЗ заказчику отдавать в откуп нельзя, поскольку исполнитель всегда «умнее», достаточно ТТ, по которым исполнитель разрабатывает ТЗ.
Что касается каши: она начинается именно с подготовки договора, в котором должно быть четко указано, по каким стандартам будет проводиться работа. Если это не указано или указано криво (эти особенно грешило Минобрнауки), то полный атас обеспечен. Тогда работа принимается исключительно за хороший откат. А с календарным планом обычно чудит сам исполнитель. неграмотно расписывая виды работ, после чего и получает люлей от всех, от кого только можно.
Вот фрагменты из Минобрнаучного ТЗ :)
«… обоснование характеристик сторонних программных средств...» — ласкает слух! Берем какую-нибудь стороннюю софтинку типа ворда и обосновываем ее характеристики — В темных очках;
«… унификация функциональных задач...» — см., уважаемые, определения функций и задач, хотя бы применительно к автоматизированным системам;
«… графических элементов интерфейсов...» — вероятно, имеются в виду элементы графического интерфейса пользователя;
«… графического интерфейса модулей...» — это уже придирка, конечно, но далеко не все программные модули оснащены графическим интерфейсом;
«… сторонних систем...» — очевидно, речь идет о внешних системах;
«… Технический акт...» — тут впору задумчиво почесать в затылке… Наверное, это что-то вроде загадочного зоологического термина «свинская собака» по Ярославу Гашеку;
«… Документ «Обоснование необходимости закупки технических средств, программного обеспечения и лицензий на него»...» — косноязычие и полное непонимание сути проблемы… Обосновывать следует закупку технических средств с конкретными характеристиками, обеспечивающими конкретный вычислительный ресурс, требуемый для нормального (штатного) функционирования комплекса программ. Программное же обеспечение, если не приобретать пиратское, всегда продается совместно с лицензией. Но дорого, однако — Круглые глаза;
«… контролем входной и выходной информации, основанной на методике кодирования объектов...» — входная информация (или данные), вводимая пользователем вручную в диалоговом (или интерактивном) режиме с помощью элементов графического интерфейса в поля ввода данных, подвергается форматно-логическому контролю, проверке неких граничных условий. Чтобы сильно не грузить читателя, приведем простой пример: форматно-логический контроль не позволит ввести, допустим, дату смерти более раннюю, чем дату рождения индивида;
«… Критерием предельного состояния Комплекса XYZ является превышение времени выполнения функций...» — уважаемые господа, посмотрите, пожалуйста, в ГОСТ 27.002, что есть предельное состояние...;
«… с возможностью «горячего резервирования» и перехода на резервное оборудование...» — налицо нарушение п. 4.2.3 ГОСТ 2.105 и явное невладение терминологией. Горячего резервирования не существует в природе, есть постоянное резервирование, которое, как известно (немногим), не требует никаких переходов (переключений). Слово «оборудование» в рамках стандартов по информационным технологиям и системам обработки информации не применяется, есть понятие «технические средства», «техническое обеспечение» и т.д.;
и, наконец, самое забавное — «… должна соответствовать требованиям эргономики и профессиональной медицины...»… Есть подозрение, что под профессиональной медициной подразумеваются СанПиНы — санитарные правила и нормы — Ржу! (смайл)
При полном адеквате схема приблизительно такая и есть. Правда, от самого заказчика хрен чего дождешься, особенно от подчиненных его, которым ни до чего нет дела. Вот и пришлось однажды объезжать все объекты Оренбурггазпрома и буквально насильно заставлять древних теток заполнять непонятные им опросные листы, чтобы хоть какие-то требования заказчика поиметь.
С ТЗ несколько иначе — оно не отвечает на вопросы, а только является перечнем требований как к функционалу, так и ко всему прочему. А на вопросы уже отвечают документы, разрабатываемые на стадии «Технический проект». Если руководствоваться ГОСТами 34-й системы, то их там дофига и больше. А для подведения итогов разрабатывается Программа и методика испытаний, по которой испытания и проводятся, по результатам испытаний составляется Акт приемки сдачи и им работа завершается. Это так, все на пальцах, в жизни сложнее бывает.
ТЗ заказчику отдавать в откуп нельзя, поскольку исполнитель всегда «умнее», достаточно ТТ, по которым исполнитель разрабатывает ТЗ.
Что касается каши: она начинается именно с подготовки договора, в котором должно быть четко указано, по каким стандартам будет проводиться работа. Если это не указано или указано криво (эти особенно грешило Минобрнауки), то полный атас обеспечен. Тогда работа принимается исключительно за хороший откат. А с календарным планом обычно чудит сам исполнитель. неграмотно расписывая виды работ, после чего и получает люлей от всех, от кого только можно.
Вот фрагменты из Минобрнаучного ТЗ :)
«… обоснование характеристик сторонних программных средств...» — ласкает слух! Берем какую-нибудь стороннюю софтинку типа ворда и обосновываем ее характеристики — В темных очках;
«… унификация функциональных задач...» — см., уважаемые, определения функций и задач, хотя бы применительно к автоматизированным системам;
«… графических элементов интерфейсов...» — вероятно, имеются в виду элементы графического интерфейса пользователя;
«… графического интерфейса модулей...» — это уже придирка, конечно, но далеко не все программные модули оснащены графическим интерфейсом;
«… сторонних систем...» — очевидно, речь идет о внешних системах;
«… Технический акт...» — тут впору задумчиво почесать в затылке… Наверное, это что-то вроде загадочного зоологического термина «свинская собака» по Ярославу Гашеку;
«… Документ «Обоснование необходимости закупки технических средств, программного обеспечения и лицензий на него»...» — косноязычие и полное непонимание сути проблемы… Обосновывать следует закупку технических средств с конкретными характеристиками, обеспечивающими конкретный вычислительный ресурс, требуемый для нормального (штатного) функционирования комплекса программ. Программное же обеспечение, если не приобретать пиратское, всегда продается совместно с лицензией. Но дорого, однако — Круглые глаза;
«… контролем входной и выходной информации, основанной на методике кодирования объектов...» — входная информация (или данные), вводимая пользователем вручную в диалоговом (или интерактивном) режиме с помощью элементов графического интерфейса в поля ввода данных, подвергается форматно-логическому контролю, проверке неких граничных условий. Чтобы сильно не грузить читателя, приведем простой пример: форматно-логический контроль не позволит ввести, допустим, дату смерти более раннюю, чем дату рождения индивида;
«… Критерием предельного состояния Комплекса XYZ является превышение времени выполнения функций...» — уважаемые господа, посмотрите, пожалуйста, в ГОСТ 27.002, что есть предельное состояние...;
«… с возможностью «горячего резервирования» и перехода на резервное оборудование...» — налицо нарушение п. 4.2.3 ГОСТ 2.105 и явное невладение терминологией. Горячего резервирования не существует в природе, есть постоянное резервирование, которое, как известно (немногим), не требует никаких переходов (переключений). Слово «оборудование» в рамках стандартов по информационным технологиям и системам обработки информации не применяется, есть понятие «технические средства», «техническое обеспечение» и т.д.;
и, наконец, самое забавное — «… должна соответствовать требованиям эргономики и профессиональной медицины...»… Есть подозрение, что под профессиональной медициной подразумеваются СанПиНы — санитарные правила и нормы — Ржу! (смайл)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разработка технического задания (ТЗ) на программный продукт с точки зрения заказчика. Работаем над ошибками