Разработка технического задания

[Munin]

serval в сообщении #1002246 писал(а):

я нашел множество умных книг и ни одной пошаговой методики. А хотелось бы именно ее.

Скажите, а вам попадалось много пошаговых методик "как сделать аэробус своими руками"? Может, там не просто по шагам надо пройти, но и ещё подумать над чем-то, ещё и знания какие-то нужны?

[rockclimber]

serval в сообщении #1002314 писал(а):

Поскольку, опыта в этом деле нет, я и пытаюсь найти апробированные методики.

Гуглите "методики моделирования информационных систем"

-- 10.04.2015, 21:29 --

Munin в сообщении #1002377 писал(а):

serval в сообщении #1002246 писал(а):

я нашел множество умных книг и ни одной пошаговой методики. А хотелось бы именно ее.

Скажите, а вам попадалось много пошаговых методик "как сделать аэробус своими руками"? Может, там не просто по шагам надо пройти, но и ещё подумать над чем-то, ещё и знания какие-то нужны?

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

[serval]

Munin в сообщении #1002377 писал(а):

а вам попадалось много пошаговых методик "как сделать аэробус своими руками"?

Не попадалось, но они есть. У производителей аэробусов. Если это не очевидно - объясняю: моя просьба адресована обладателям интересующей меня технологической документации либо могущим помочь в ее получении. Хотя бы, практически полезным советом.
Запретить не могу, но убедительно прошу не засорять топик высокомудрыми сентенциями.

[AlexDem]

serval в сообщении #1002314 писал(а):

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

Мне кажется, методики здесь быть не может. Этот что-то вроде темы "ТРИЗ для физиков", которая здесь одно время всплывала. Вам нужен эксперт (или несколько), на пару с которым Вы будете работать над улучшением техпроцессов. Заодно ответственность с себя частично снимете.

serval в сообщении #1002267 писал(а):

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

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

-- менее минуты назад --

(Чтобы выбрать понравившееся, нужно изучить несколько, конечно)

[Munin]

serval в сообщении #1002539 писал(а):

Не попадалось, но они есть.

Если вы в это верите, это не значит, что они на самом деле есть.

serval в сообщении #1002539 писал(а):

Запретить не могу, но убедительно прошу не засорять топик высокомудрыми сентенциями.

Я попытался объяснить вам "на пальцах" то, что вам и так пытаются объяснить другие собеседники. Не вышло.

[mserg]

Некоторые общие черты в этом деле все же есть.

Деятельности любой компании (зд. – учебного заведения) делится на:
* Текущую
* Развитие

Единица развития есть проект. Двигают проекты специальные «проектные офисы» компаний, состоящие, в основном из «бизнес-аналитиков» и менеджеров проектов.

Проект начинается с постановки цели – что хотим достичь? Всегда нужно четко иметь ответ на вопрос, каковы критерии успешного завершения проекта?

Работа компании до реализации проекта есть «как есть», а после реализации проекта работа компании есть «Как должно быть». Проект должен реализовать все шаги по этому переходу.

Потребности компании называются «требованиями». Нередко есть специальное программное обеспечение, куда «проверенные» сотрудники непрерывно заносят требования. Специалисты, которые понимают, как работает бизнес, расставляют приоритеты этим требованиям и выставляют «срочность». Из этого массива требований формируют «проекты», которые «двигает» проектный офис.

В любом случае, создание технического задания предваряется сбором требований. ТЗ – это описание «технического решения» по реализации требований. Но это не совсем односторонняя связь: сотрудникам, которые формируют требования, и оценщикам приоритетов и срочностей, нужно примерно знать, что и сколько стоит – на этом зиждется эффективность.

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

В общем
* Узнаем цель
* Составляем требования
* Готовим техническое решение
* Если оцениваемая эффективность низкая, начинаем новую итерацию: уточняем цель, уточняем требования и т.д.

[serval]

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

[rockclimber]

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

[AlexDem]

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

[serval]

Совершенно согласен. С радостью пойду на поводу у подрядчика, но пока он ограничился двумя анкетами.

[AlexDem]

А, так Вы заказчик? Так сколько, говорите, перпендикулярных красных линий Вам нужно?..
Тогда Вам можно предложить подрядчику составить примерный план по этапам проекта со сроками. И запросить у него какие-то типовые решения - чтобы было на что ориентироваться. Если у него их нет, то придётся искать Вам, но тогда доля его участия в проекте меньше, денег он должен получить тоже меньше.

-- менее минуты назад --

И ещё можно запланировать регулярные встречи, если он, на Ваш взгляд, тянет волынку. Что-нибудь говорить на таких встречах ему придётся, так что хоть как-то, но работа должна будет продвигаться. А если нет - Вам это станет понятно гораздо раньше.

[serval]

Я просил типовые решения. Видимо, их нет.

[AlexDem]

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

[michael_tok]

serval в сообщении #1003722 писал(а):

Я просил типовые решения. Видимо, их нет.

Ветка заглохла?
Типовые решения есть всегда!
Есть шаблон нормального ТЗ. По нему написано не менее 50 проектов. Если интересно - идите в личку. Если интересно народу, могу подсказать подробнее тут.

[Kosterik]

michael_tok в сообщении #1041835 писал(а):

Есть шаблон нормального ТЗ. По нему написано не менее 50 проектов. Если интересно - идите в личку. Если интересно народу, могу подсказать подробнее тут.

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