Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: Технические Задания  (Прочитано 9797 раз)
0 Пользователей и 1 Гость смотрят эту тему.
FallenSoul
Опытный

ru
Offline Offline
Пол: Мужской

« : 05-07-2009 11:31 » 

Добрый день. Хотел бы узнать, где можно покопаться и поискать ТЗ на разработку всяких систем управления для предприятий/фирм?
Дело в том, что давно хотел заняться написанием нечто подобного для практики разработки большого проэкта на C++/ C# .NET с привязкой к бд MS SQL Server. Спасибо Улыбаюсь
Записан
Dimka
Деятель
Модератор

ru
Offline Offline
Пол: Мужской

« Ответ #1 : 05-07-2009 19:36 » 

Сложно. Такие ТЗ как правило содержат приватную информацию о заказчике, поэтому вот так вот запросто их не получить.

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

Вот ТЗ на продукты (рыночные) найти легче, однако, наверно, это не вполне то, что тебе нужно.

Языки и технологии для составления ТЗ на подобные решения - очень и очень вспомогательная вещь. Как правило, они рассматриваются (если даны заказчиком) как системное условие/ограничение (constraint). Основной упор делается на предметную область и бизнес-процессы. Т.е. вначале бизнес-аналитик собирает бизнес-требования, а потом в ТЗ пишут, что нужно эти требования реализовать при указанных ограничениях (сроки, бюджет, предпочитаемые инструментальные средства, ссылки на существующую инфраструктуру).

ТЗ рассматривается как контракт. А фирму интересуют не столько SQL Server и т.п., сколько тот операционный и экономический эффект, который даст внедрение заказываемой информационной системы. И всё сводится к тому, что прямые и косвенные эффекты в обозримом будущем должны превосходить затраты на разработку, внедрение и последующее сопровождение. Например, автоматизация какой-то бизнес-процедуры может дать не только прямой эффект в виде сокращения операционных затрат фирмы, но и косвенный - например, конкурентное преимущество от ускорения и/или повышения качества выполнения этой процедуры.
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
FallenSoul
Опытный

ru
Offline Offline
Пол: Мужской

« Ответ #2 : 05-07-2009 20:05 » 

Виноват, не правильно значит по поводу ТЗ выразился. Имел ввиду видимо постановку задачи, которую требуется реализовать без экономических обоснований и пр.

Вот например думал попробовать реализовать систему учёта продукции магазина, продажи/завоз/наличие товара на складе, вывод отчётов и пр. но увы своей фантазии не хватит для того, чтобы сделать всё "по правилам" и учесть все аспекты требуемые реальному предприятию/фирме для работы. Думал что в ТЗ всё расписывают до мелочей, но теперь понимаю что нет =\ надо в другом направлении копать
Записан
Kivals
Команда клуба

us
Offline Offline
Пол: Мужской

WWW
« Ответ #3 : 06-07-2009 08:19 » 

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

ru
Offline Offline
Пол: Мужской

« Ответ #4 : 06-07-2009 10:30 » 

Kivals, ух Улыбаюсь Спасибо!
Записан
Dimka
Деятель
Модератор

ru
Offline Offline
Пол: Мужской

« Ответ #5 : 06-07-2009 13:27 » 

Цитата: Kivals
ссылки на ГОСТы
ГОСТы на АСУ 70-90-х годов полезно почитать для общего развития. В содержательной части (что должно быть предусмотрено при разработке АСУ) они весьма толковые, но в методологической части (управления проектом, структуры документации и программно-аппаратной инфраструктуры) они, очевидно, сильно устарели и поэтому требуют творческого переосмысления.

Цитата: FallenSoul
Вот например думал попробовать реализовать систему учёта продукции магазина, продажи/завоз/наличие товара на складе, вывод отчётов и пр. но увы своей фантазии не хватит для того, чтобы сделать всё "по правилам" и учесть все аспекты требуемые реальному предприятию/фирме для работы. Думал что в ТЗ всё расписывают до мелочей, но теперь понимаю что нет =\ надо в другом направлении копать
Любая система из того класса, который тебя интересует - это в первую очередь многоуровневый анализ требований, в котором технические решения (собственно проектирование программ и программирование) подчиняются управленческим решениям. Подчинение принимаемых решений и выбираемых стратегий на более низких уровнях требованиям и ограничениям более высоких уровней называется трассировкой. Грубо говоря, если в приложении есть какая фича или просто кнопочка - всегда должны быть понятны те требования, для выполнения которых программист эту фичу или кнопочку придумал. В программной системе нет случайных и лишних вещей.

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

При всём том довольно часто само руководство, инициирующее такой проект, не осознаёт всех аспектов влияния внедряемой АСУ на работу вверенного им предприятия и необходимых затрат - не только прямых (оплата работы программистов), но и косвенных (реорганизация деятельности предприятия). Я лично адекватных руководителей видел только на крупных предприятиях (в структурах бывшего РАО ЕЭС, на предприятях Силовых машин). Конечно, для одного магазина (не сети) всё более неформально и потому дешевле, но, тем не менее, всесторонность и системность в работе всё равно необходима. И только на уровне отдельного ларька с парой сменных продавцов можно сразу кинуться в программирование.


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

Я лично для себя выделяю трёхуровневую матрицу вопросов "зачем?" "что?" и "как?". И эта матрица упорядочивает все уровни требований и принимаемых решений.

Например, применительно к твоей системе можно задать вопрос "зачем (она нужна)?" Наверно, ответ на этот вопрос будет достаточно короткий. Что-то в духе: "Мы хотим попробовать уменьшить нашу дебиторскую (и, возможно, кредиторскую) задолженность, складские запасы, долю списываемого просроченного товара и т.д." Такая довольно очевидная для кризисных времён проблема. Следующий вопрос "что (система должна делать)?". И, возможно, он будет выглядеть как: "Для этого мы хотим реорганизовать и автоматизировать учёт движения товаров, чтобы повысить оперативность информирования руководства магазина о товарном обороте. Это позволит более своевременно и точно принимать решения по взаимодействую с поставщиками и проведению маркетинговых акций (реклама, скидки, распродажи и т.п.)" Следующий вопрос: "как (система должна реорганизовать и автоматизировать учёт)?" Ответ обычно состоит из 2-х частей: описания "как оно есть сейчас" и описания "как оно должно быть" - тут могут быть самые разные истории про то, что из нашего 1С-решения нельзя получить такие-то агрегированные данные, нужные для принятия управленческих решений, или про то, что приёмка товаров на складе проводится не так, как хотелось бы и т.д.

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

Сдвигаемся на уровень ниже. В нём уже есть ответы на вопросы "зачем?" (чтобы реогранизовать и автоматизировать учёт) и "что?" (нужны отчёты с такими-то агрегированными данными, но 1С их не предоставляет). Возникает следующий вопрос: "как (эти отчёты получить?)" Тут тоже масса вариантов: и модификация конфигурации 1С (с последующей проблемой обновлений), и разработка собственной системы, интегрированной с 1С, которая либо вводит недостающие в 1С данные, а отчёты строит по данным из 1С и их своей БД (этот вариант очевидно неудобен для ручного ввода в 2 программы), либо предоставляет свой интерфейс для ввода всех данных, и часть из них сама копирует в 1С. Тут же определяются пользователи системы (с каких рабочих мест вручную или из каких других программных решений путём экспорта/импорта в разрабатываемую систему будут поступать данные). Структуры данных и содержание отчётов можно наметить, но, как правило, со временем у заказчика появляются новые "хотелки". Это значит, что основной задачей на этом уровне является не разработка форм отчётов и ввода данных (это ещё рано) разработка технологии получения, хранения и обработки данных в условиях оговоренной аппаратно-программной инфраструктуры (ОС, уже эксплуатируемые АСУ и прочие информационные системы, какие-нибудь там POS-терминалы, СУБД и т.д.) Того, что называется системной архитектурой.

Так проводится анализ и сбор требований, которые формируют собственно ТЗ. На каждом уровне можно остановиться и зафиксировать соглашения. Каждый следующий уровень добавляет новые принятые решения и уменьшает энтропию системы (пространство для манёвра разработчика). Тут очень важно не уменьшить энтропию сразу. Когда в ответ на "Мы хотим попробовать уменьшить нашу дебиторскую (и, возможно, кредиторскую) задолженность, складские запасы, долю списываемого просроченного товара и т.д." сразу говорят: "Ща мы вам напишем программу на C++ и SQL Server - она решит все ваши проблемы". Очевидно, что непрофессиональный и (по здравому рассуждению) нелогичный подход, поскольку совершенно не ясно, как SQL Server связан со складскими запасами, и нужен ли он вообще для более эффективного управления ими.

Те ответы на вопросы зачем, что и как, которые я выше написал - это грамотные ответы. Их можно и в книжках прочитать, когда там разные примеры разбирают. Но в 99% случаев руководители предприятий не являются бизнес-аналитиками. Это значит, что такие ответы руководители не дадут. Если они (начитавших интернетов и посоветовавшись с друзьями) начинают рассуждать про базы данных, программы и говорить, что эти программы должны делать - это всё можно записать, но скорее всего оно либо не пригодится вовсе, либо пригодится в неполном виде. Поскольку за всем этим нет ответов на вопросы "зачем?" и "что?" Руководители сразу переходят к ответу "как (оно им видится)", считая, что плоды их размышлений над проблемой - либо их личное дело, либо и так всё очевидно. Как правило, это привычка руководителей решать единолично и, не откладывая в долгий ящик, сразу переходить к делу (особенно сильна у мелких предпринимателей, неискушённых в аппаратной работе в бюрократической среде); при этом разработчика такой руководитель рассматривает в роли такого же исполнителя его замыслов, как и своих сотрудников.

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

Поэтому реальную проблему, которую должна решить система, нужно из руководителя выуживать из под шелухи его придумок. Проблему он знает, но обращается к разработчикам уже после "Я тут думал-думал и придумал вот что: ..." И при этом разговор надо вести аккуратно - так, чтобы у такого руководителя не возникало ощущения, что эти молодчики-консультанты тут за него начнут распоряжаться на его предприятии, или что его собственные задумки - форменная глупость, а сам он - полный дурак. Как говорится: "Входить к начальнику нужно со своим мнением, а выходить - с мнением начальника." Улыбаюсь
« Последнее редактирование: 06-07-2009 18:17 от Dimka » Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
FallenSoul
Опытный

ru
Offline Offline
Пол: Мужской

« Ответ #6 : 06-07-2009 14:28 » 

Dimka, всё прочитал Улыбаюсь

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

Увы похоже слишком всё серьёзно в моём вопросе восприняли, и в 3 этожа раздули. Я обычный, ничем не примечательный программистик, который хотел бы с целью практики, в домашних условиях побаловаться, но ввиду отсутствия фантазии и желания реализовывать авось-как лишь искал ответа на вопрос: где можно поискать детализированное описание функций АСУ под конкретное предприятие того или иного размера Улыбаюсь Сори если изначально не так выразился, и отнял у кого-то время
Записан
Sla
Команда клуба

ua
Online Online
Пол: Мужской

WWW
« Ответ #7 : 06-07-2009 14:42 » 

FallenSoul, у... как все запущено...
Умерла так умерла...
Ты хотел узнать, узнал
А теперь действуй.
И для примера можешь выложить свое ТЗ.

А еще проще, не знаю как там с образованием (высшее/не высшее) ТЗ на проектирования АСУ в пунктах не отличается от ТЗ на дипломный проект. Разница скорей всего будет в  полноте детализации  проекта, ну и прочих вкусностей, таких как, например, возможный рефакторинг.
Записан

Мы все учились понемногу... Чему-нибудь и как-нибудь.
Dimka
Деятель
Модератор

ru
Offline Offline
Пол: Мужской

« Ответ #8 : 06-07-2009 15:13 » 

Цитата: FallenSoul
Я обычный, ничем не примечательный программистик, который хотел бы с целью практики, в домашних условиях побаловаться, но ввиду отсутствия фантазии и желания реализовывать авось-как лишь искал ответа на вопрос: где можно поискать детализированное описание функций АСУ под конкретное предприятие того или иного размера
Ну баловаться-то можно собственно в программировании. Но результаты этого баловства не будут "системой управления для предприятия/фирмы" - это будет просто программка, непонятно как связанная с областью её применения. Этакий "сферический конь в вакууме", созданный ради удовольствия пописать программки.

Как только речь зайдёт о внедрении программки в магазин, всплывут все эти трёхэтажные вопросы, а то ещё и придётся всё выбросить и начать с начала.
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
FallenSoul
Опытный

ru
Offline Offline
Пол: Мужской

« Ответ #9 : 11-07-2009 01:32 » 

Добрый день. Вот например.

Цитата
Разработка программы: «База данных компьютеров и комплектующих»
Автоматизированная система учета закупок и реализации компьютерной техники
Система предназначена для автоматизации работы организации, занимающейся поставкой компьютерной техники.
Система обеспечивает:
а) ведение базы данных производителей, товаров и групп товаров;
б) регистрация прихода и расхода товара;
в) определение наличия товара на складе;
г) формирование готовых системных блоков из комплектующих в наличии на складе;
д) формирование прайс-листа магазина.
е) формирование следующих отчетных и первичных документов:
–прайс-лист;
–товар в наличии на складе;
–книга продаж за заданный интервал дат;
–книга покупок за заданный интервал дат;
–счет;
–накладная;
–товарный чек.

Главный вопрос для меня сейчас состоит в сборе информации по каждому пункту.
Цитата
б) регистрация прихода и расхода товара;
Должны быть формы(карточки) для регистрации, в карточках реквизиты- гуглил, всё плохо. Целая наука партийных, не партийных приходов товара, и огромное кол-во не лицеприятных терминов.
Цитата
е) формирование следующих отчетных и первичных документов:
–счет;
–накладная;
–товарный чек.
Опять же следующие документы я не могу знать, следовательно нужные формы и данные по реквизитам для их заполнения.

Не имея информации, не могу начать проектировку БД, и уж тем более писать какой-никакой код.  Здесь была моя ладья...
Подскажите мои дальнейшие действия будь Вы на моём месте? Поиск с анализом данных, или обращение в специализированные источники?

п.с. По работе с АИС у нас существуют ФАПы утверждённые Министерством Транспорта. Вот там всё четко и по полочкам разложено- кто, что, кому и в какой форме.
Записан
Dimka
Деятель
Модератор

ru
Offline Offline
Пол: Мужской

« Ответ #10 : 11-07-2009 09:57 » 

Помнится, лет 7 назад по одной только книге покупок я на 3-м курсе вместе с 5-икурсниками (был один преподаватель и фактически один и тот же предмет, только в двух частях на 3 и 5 курсах) разрабатывал проект - там в отчёте вышло что-то около 30-50 страничек с кучей форм первичной отчётности. Ведь эта штука тянет за собой все виды оформления покупок: за наличный, безналичный расчёт, с акцизами и без, с таможенными документами, товарными накладными, счетами-фактурами и т.д. Очень удобно такие вещи писать внутри готовой инфраструктуры, где акцизы, НДС, таможня и всё прочее вынесено в отдельные модули - тогда, действительно, это просто 1 журнал, в который ставится дата, ссылка на регистрационный документ и сумма.

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

Цитата: FallenSoul
Не имея информации, не могу начать проектировку БД, и уж тем более писать какой-никакой код.
До БД и кода тебе ещё как до Луны. В начале чётко и до мелочей разбери предметную область и определи границы разрабатываемой системы - что она должна делать, что она не должна (или не будет) делать, и как и кто будет делать то, что не будет делать система. Тебе её надо включить в процесс работы фирмы.

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

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
x77
Команда клуба

ro
Offline Offline
Пол: Мужской
меняю стакан шмали на обратный билет с Марса.


« Ответ #11 : 19-07-2009 12:56 » 

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

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

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

во-вторую очередь я бы посмотрел в сторону шаблонов проектирования и так называемого "объектно-ориентированного бизнес-анализа". одна из лучших вещей на эту тему: "Крэг Ларман: Применение UML и шаблонов проектирования" (понадобиться читалка для формата dejavu)

в книге на примере разбирается составление ТЗ для сравнительно небольшой программулины. по сути, это даже не столько ТЗ, сколько очень хороший пример вменяемой проектной документации, которая будет понятна любому вменяемому программеру. кроме того, использование UML сейчас достаточно "модно" Улыбаюсь
« Последнее редактирование: 19-07-2009 13:02 от x77 » Записан

Dimka
Деятель
Модератор

ru
Offline Offline
Пол: Мужской

« Ответ #12 : 19-07-2009 14:21 » new

Цитата: x77
хорошее ТЗ само по себе стоит сравнимо с готовым продуктом и может занимать больше времени, чем написание самого продукта.
Из моей практики одно ТЗ писалось и согласовывалось 4 месяца, а первая версия продукта 2-3 месяца. В другом случае спецификации собирались 3 месяца, а продукт писался 1 месяц, но после внедрения заказчик решил вообще всю инфраструктуру поменять, поэтому в эксплуатации продукт пробыл только 2 месяца. И это всё были небольшие продукты для больших предприятий. К вопросу об эффективности работы.
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines