Друзья,

сейчас веду курс "Архитектура ИС". Дается тяжело, но интересно. Мир не без добрых людей, помогают. Советом, делом. Большое им спасибо. Особая благодарность Дмитрию Безуглому, Кириллу Лебедеву, но поболее всего Леониду Борисовичу Новикову!
Постепенно вырисовываются контуры правильной дисциплины.

Цикл проектирования архитектуры обычно (типично) включает анализ требований, системный функциональный анализ, архитектурный анализ и проектирование архитектуры (ну с вариациями). Изучение литературы, примеров, показывает, что на входе типично нужны Потребности заинтересованных лиц и Системные требований (по крайней мере по требований методики harmony и других), методика ADD (attribuite driven development)  требует на входе списка функциональных требований, проектных ограничений и атрибутов качества.

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

Для начала проектирования достаточно концепции, далее уже отдать для написания ТЗ и Архитектуры.
Концепции можно написать в вольном стиле на одну страничку (у меня такие есть штук 5 для своих курсов по требованиям), но написать их займет пол дня.
Варианты заданий можно взять у нас на форуме или погуглить, вот например:
https://www.google.ru/search?q=%D0%B7%D0%B0%D0%B4%D0%B0%D0%BD%D0%B8%D1%8F+%D0%B4%D0%BB%D1%8F+uml

на входе типично нужны Потребности заинтересованных лиц и Системные требований (по крайней мере по требований методики harmony и других), методика ADD (attribuite driven development)  требует на входе списка функциональных требований, проектных ограничений и атрибутов качества.

Я бы дополнил перечень входных данных:
1. Пониманием перспектив развития ИС за рамками текущих работ. Развития функционального, интеграционного, нагрузочного. Перспективы должны учитываться не только те, которые просто не уместились в рамки проекта, но и (по возможности) те, которые возникнут как следствие появления ИС.
2. Преимуществ и ограничений собственных возможностей (имеющихся компетенций, опыта, лицензий и т.п.).

Я бы дополнил перечень входных данных:
1. Пониманием перспектив развития ИС за рамками текущих работ. Развития функционального, интеграционного, нагрузочного. Перспективы должны учитываться не только те, которые просто не уместились в рамки проекта, но и (по возможности) те, которые возникнут как следствие появления ИС.
2. Преимуществ и ограничений собственных возможностей (имеющихся компетенций, опыта, лицензий и т.п.).

Леонид, спасибо. Правда, если честно, не совсем понял всех нюансов Вашего уточнения.
1. О перспективах - да я понимаю, что можно (и нужно) включить определенные вводные, которые могут быть (или должны) отражены в соответствующем решение. Вы это имеете в виду?
2. и понятно и не очень. С одной стороны понятно, что студент хочет не хочет будет опираться на свои возможности. Что Вы предлагаете, конкретно?

Итожу, можно, пусть на пальцах, но по точнее? Некоторые заметки по кейсу - здесь: http://yadi.sk/d/idePSkO0LPBw3

В закромах нарыл вот такие задания, у кого какое мнение?

Леонид, спасибо. Правда, если честно, не совсем понял всех нюансов Вашего уточнения.
1. О перспективах - да я понимаю, что можно (и нужно) включить определенные вводные, которые могут быть (или должны) отражены в соответствующем решение. Вы это имеете в виду?

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

а) "Не уместились в рамки проекта" - тут все просто. Например, хотелок у заказчика на 12 модулей, а времени и денег - только на 6. Но пока мы будем делать эти 6, заказчик подумывает раздобыть еще денег. Поэтому мы в архитектуре учитываем, что "дружить" между собой придется 12 модулей, а не 6, как сказано в  ТЗ текущего контракта.

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

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

* не будем рассматривать случай, когда ИС создается по требованию "то же самое, но с зелеными кнопками".

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

Выбранная (спроектированная) архитектура потребует для реализации вполне определенных ресурсов (людей, компетенций, времени и т.п.). Если мы решили, наш новый проект будет на модной SOA + web, а у нас на руках только дельфисты (джависты закончат свои текущие проекты не раньше, чем через полгода), то возможно, нам стоит подумать еще раз. А по итогам раздумий, не выделываться и сделать обычную двузвенку на дельфи+sql (благо, ее для решения задачи хватит).
Или противоположный вариант: у нас совершенно нет компетенций в том сегменте, на который мы стратегически нацелились. Зато есть заказчик, который, по всем признакам, стерпит роль подопытного кролика. Вот мы и проектируем архитектуру, которая ему не сильно показана (но задачи решает), а нам крайне нужна, поскольку позволит получить нужные компетенции, опыт и укомплектовать свой штат.

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

В закромах нарыл вот такие задания, у кого какое мнение?

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

А что от студента ожидается на выходе? В какой форме?

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

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

Касаемо технологий - мы не рассчитываем на создание какого-то решения.  Думаю, в этом случае интересен выбор студентов и обоснование этого выбора.

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

Так понятно, что это руда, которую следует переделать под нужное задание. Я же и обратился сюда за конкретной, а не теоретической помощью. Мне не только совет хотелось бы получить, мне бы хотелось получить исходные данные для решения задачи.

А что от студента ожидается на выходе? В какой форме?

Здесь я разместил небольшие разработки http://yadi.sk/d/idePSkO0LPBw3.
1. хотелось бы получить несколько вариантов системных проектов (вариаций архитектур, стилей)
 например - клиент-серверная архитектура с тонким клиентом, с толстым клиентам или с выделенным сервером-приложений - с указанием + и - и обоснованием выбора (с учетом постановки и разных вводных)
2.  постараться отработать процесс проектирования архитектуры (изучить какую-то методу ADD, RUP, ICONIX, свою наработку..)
3. научить использовать для этого UML например
4. научить пониманию причинноследственных связей принимаемых решений

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

2. ограниченность курса и ограничения нашей специальности - у нас не программисты, а специалисты по ИС, которые в лучшем случае становятся прикладными программистами, больший упор на БД, аналитику, управление сетями, адимнистрирование

...
Я же и обратился сюда за конкретной, а не теоретической помощью. Мне не только совет хотелось бы получить, мне бы хотелось получить исходные данные для решения задачи.
Здесь я разместил небольшие разработки http://yadi.sk/d/idePSkO0LPBw3.
...

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

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

Собрать несколько комплектов условий, приближенных к реальным и отправить студента "действовать".

Например:

---
Компании А требуется наладить сбор важной еженедельной отчетности установленных форм из своих филиалов в центральный офис в столице.
Сведения о компании:
1. У компании большой бюджет на создание решения, но на дальнейшее сопровождение он будет очень скромным.
2. Количество филиалов на текущий момент 315, в следующем году планируется открыть еще 112.
3. У компании есть избыточное количество лицензий на серверное ПО и СУБД от Майкрософт (закупленное для другого, провалившегося проекта).
4. Каналы связи у филиалов следующие: 50% - 1 гигабит и более, 25% - 512-256 килобит, 20% - 33,6 килобит, 5% - не имеют подключения.
5. ИТ-службы у компании есть только в 1/3 филиалов, в основном - в крупных городах.
6. У компании есть веб-сайт с форумом для своих сотрудников.
7. Отчетность в филиалах компании ведется в Excel.
Задание:
Предложите архитектуру информационной системы для решения задачи компании и обоснуйте его.
---

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

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

Да, я их бегло просмотрел еще перед первым ответом. Уж очень они "небольшие".

Ну во-первых, я не успеваю все перевести, потому скорее тезисы.
во-вторых, сколько книг не использовал, никогда нормальных хорошо прописанных примеров не видел, все такие схематичные.
Или если есть методика, то чтобы ее реализовать в полном виде, нужно не 15 пар, я раз в больше:(

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

Ну естественно. Вы же сами постоянно утверждаете, что практика отличается от теории. Это естественно.

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

Обыгрываются какие указанные материалы? Учебный кейс?

Нет не совсем, в slideshare я выложил 5 первых презентаций. Вы можете глянуть, если интересно из "первоисточника" http://yadi.sk/d/27r1YiWFGNgSr.

Если же студентам рассказано о 3-4 вариантах популярных архитектурных решений, описаны их преимущества и недостатки (не только в целом, но и отдельных составляющих), можно кое-то придумать.

Да без подобного лекции по архитектуре невозможны. Правда, я не нашел в литературе хорошо прописанные варианты популярных решений. Используются примеры конкретных решений, например facebook.

Собрать несколько комплектов условий, приближенных к реальным и отправить студента "действовать".
Например:
---
Компании А требуется наладить сбор важной еженедельной отчетности установленных форм из своих филиалов в центральный офис в столице.
Сведения о компании:
1. У компании большой бюджет на создание решения, но на дальнейшее сопровождение он будет очень скромным.
2. Количество филиалов на текущий момент 315, в следующем году планируется открыть еще 112.
3. У компании есть избыточное количество лицензий на серверное ПО и СУБД от Майкрософт (закупленное для другого, провалившегося проекта).
4. Каналы связи у филиалов следующие: 50% - 1 гигабит и более, 25% - 512-256 килобит, 20% - 33,6 килобит, 5% - не имеют подключения.
5. ИТ-службы у компании есть только в 1/3 филиалов, в основном - в крупных городах.
6. У компании есть веб-сайт с форумом для своих сотрудников.
7. Отчетность в филиалах компании ведется в Excel.
Задание:
Предложите архитектуру информационной системы для решения задачи компании и обоснуйте его.
---

Спасибо за пример. Интересно было бы посмотреть на ваше решение Хотя бы схематичное.
Я бы например решил задачу просто через google.docs, ну или, если имеется сайт, то можно наладить ftp сервис.
Если 5 % филиалов не имеет подключения, то они никак не могу передать отчетность. Если же у них есть телефон, то значит они могут отправить данные по модему.

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

Также, а что значит "действовать"?

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

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

Обыгрываются какие указанные материалы? Учебный кейс?

По первый ссылке на яндекс. Там, где куча презентаций.

Вы можете глянуть, если интересно из "первоисточника" http://yadi.sk/d/27r1YiWFGNgSr.

Глянул. Поплохело. Детей жалко.

Спасибо за пример. Интересно было бы посмотреть на ваше решение Хотя бы схематичное.

Я бы например решил задачу просто через google.docs, ну или, если имеется сайт, то можно наладить ftp сервис.
Если 5 % филиалов не имеет подключения, то они никак не могу передать отчетность. Если же у них есть телефон, то значит они могут отправить данные по модему.

Хорошо. Ниже.

Также, а что значит "действовать"?

Приступить к решению задачи.

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

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

Один из вариантов решения.

1. Для сбора отчетов будем использовать:
а) Корпоративный сайт (разработаем и встроим в него свои формы).
б) Электронную почту.
2. Все присылаемые отчеты будут проверяться на соответствие правилам ФЛК.
3. Отправитель будет уведомляться о результатах приемки отчета (когда получен, каковы результаты ФЛК, принят или нет):
а) если отчет подавался посредством сайта - то прямо на сайте и письмом в почту;
б) если отчет подавался по почте - ответным письмом в почту.
4. Для идентификации отправителей используем:
а) данные учетных записей на сайте;
б) адреса корпоративной почты.
5. Создадим механизм контроля, которая позволит показать на любой момент времени (включая текущий), кто и когда сдал (или не сдал) отчет за заданный период. Механизм потребуется для:
а) действий персонала по обеспечению собираемости отчетов;
б) контроля исполнения распоряжения первого лица компании "О предоставлении отчетности форм А, Б, Ц" от ....
6. Создам механизм статистической (нарастающим, по территориальному делению и т.п.) и аналитической (сравнение с АППГ, корреляция, экстраполяция и т.п.) обработки собранных отчетов.
7. Для обеспечения корректности расчетов и отображения исторических данных, создадим механизм ведения реестров филиалов (когда открыт, как назывался и переименовывался, кому подчинялся, когда был закрыт и т.п.).

Архитектура на рисунке. Зеленым - создаваемые компоненты решения.

Модуль Парсинга должен:
- Проверять указанную почту на предмет получения отчетов в формате xls.
- Принимать отчет с сайта в виде xls.
- Принимать отчет с сайта в виде xml (из формы, заполненной непосредственно на сайте).
- Управлять очередью обработки отчетов (отчеты, поданные через сайт, обрабатываются в режиме реального времени, почтовые - в остальное время).
- Проверять отчет на соответствие правилам ФЛК.
- Формировать и отправлять результаты обработки отчета:
а) в виде электронного письма по шаблону на адрес электронной почты, связанный с отчетом;
б) в xml для вывода на сайте.
- Сохранять принятый отчет в БД.

Модуль Парсинга взаимодействует с Формой ввода/загрузки отчета на корпоративном сайте.
Форма должна позволить пользователю:
1. Приложить и отправить отчет в виде xls-файла (идентификационные данные отправителя передаются в Парсер автоматически).
2. Заполнить отчет в онлайн форме и отправить его.
3. Получить ответ о результатах обработки в режиме реального времени.

Модуль Контроля поступления отчетов должен:
1. По запросу с сайта (период отчетности, дата) вернуть список филиалов, от которых ожидается отчет со сведениями о его предоставлении (кто, когда представил) или непредоставлении.

Интерфейсом модуля Контроля является страница на корпоративном сайте.

Модуль ведения НСИ...
1. Ведение реестра филиалов.
...

Модуль статистики/аналитики...
...

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

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

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

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

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

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

Впрочем, соглашусь, что интересно общее решение, а не архитектура частного приложения.

Один из вариантов решения.

1. Для сбора отчетов будем использовать:
а) Корпоративный сайт (разработаем и встроим в него свои формы).
б) Электронную почту.

Согласен, это следует из постановки задачи. Упоминается сайт, почта в данном случае очевидна.

2. Все присылаемые отчеты будут проверяться на соответствие правилам ФЛК.

1. что такое ФЛК?
2. к какому из 7 перечисленных пунктов + само задание это относится? Как кто-то вне вашегго понимания задачи сумеет догадтся о ФЛК и потребности проверки?

3. Отправитель будет уведомляться о результатах приемки отчета (когда получен, каковы результаты ФЛК, принят или нет):
а) если отчет подавался посредством сайта - то прямо на сайте и письмом в почту;
б) если отчет подавался по почте - ответным письмом в почту.

Об этом следует догадаться. КАкие рассуждения должны привести студента к данному (думаю важному ) моменту

4. Для идентификации отправителей используем:
а) данные учетных записей на сайте;
б) адреса корпоративной почты.

Хорошо, но сможет ли студент догадаться это учесть?

5. Создадим механизм контроля, которая позволит показать на любой момент времени (включая текущий), кто и когда сдал (или не сдал) отчет за заданный период. Механизм потребуется для:
а) действий персонала по обеспечению собираемости отчетов;
б) контроля исполнения распоряжения первого лица компании "О предоставлении отчетности форм А, Б, Ц" от ....

хорошо

6. Создам механизм статистической (нарастающим, по территориальному делению и т.п.) и аналитической (сравнение с АППГ, корреляция, экстраполяция и т.п.) обработки собранных отчетов.

Можно догадаться, но без опыта сложно (студентов имею в виду)

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

Логически можно вывести, но мне например в голову не пришло.

Архитектура на рисунке. Зеленым - создаваемые компоненты решения.

А в чем различие двух рисунков, я не заметил

Модуль Парсинга должен:
- Проверять указанную почту на предмет получения отчетов в формате xls.
- Принимать отчет с сайта в виде xls.

про этот формат мы можем догадаться из постановки, хотя есть и формат xlsx
 

- Принимать отчет с сайта в виде xml (из формы, заполненной непосредственно на сайте).

Это можно только придумать, нет в постановке ничего подобного, хотя логика понятна

- Управлять очередью обработки отчетов (отчеты, поданные через сайт, обрабатываются в режиме реального времени, почтовые - в остальное время).
- Проверять отчет на соответствие правилам ФЛК.
- Формировать и отправлять результаты обработки отчета:
а) в виде электронного письма по шаблону на адрес электронной почты, связанный с отчетом;
б) в xml для вывода на сайте.
- Сохранять принятый отчет в БД.

Модуль Парсинга взаимодействует с Формой ввода/загрузки отчета на корпоративном сайте.
Форма должна позволить пользователю:
1. Приложить и отправить отчет в виде xls-файла (идентификационные данные отправителя передаются в Парсер автоматически).
2. Заполнить отчет в онлайн форме и отправить его.
3. Получить ответ о результатах обработки в режиме реального времени.

Модуль Контроля поступления отчетов должен:
1. По запросу с сайта (период отчетности, дата) вернуть список филиалов, от которых ожидается отчет со сведениями о его предоставлении (кто, когда представил) или непредоставлении.

Интерфейсом модуля Контроля является страница на корпоративном сайте.

Модуль ведения НСИ...
1. Ведение реестра филиалов.
...

Модуль статистики/аналитики...
...

В принципе понятно, но мне кажется, подобное решение должно как-то выводится. У вас по функциональному признаку, но мне кажется не вся информация может быть извлечена из постановки, сумеют ли студенты допридумать? У меня сомнения

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

Хорошо

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

Почему именно три, как определить, что трех достаточно

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

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

В принципе мне Ваше решение нравится. Какова его методологическая основа? Спасибо!

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

Очень мало знаком. В последний раз копался и программировал в 1С в 2000 году. Но чутье подсказывает, что единичное приложение (т.е. exe-файл со своим "обвесом") из набора 1С имеет только одну архитектуру. Решение на нем - другое дело.

1. что такое ФЛК?

Форматно-логический контроль.

2. к какому из 7 перечисленных пунктов + само задание это относится? Как кто-то вне вашегго понимания задачи сумеет догадтся о ФЛК и потребности проверки?
Об этом следует догадаться. КАкие рассуждения должны привести студента к данному (думаю важному ) моментуХорошо, но сможет ли студент догадаться это учесть?

И остальное в ключе "не следует из постановки".

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

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

Логически можно вывести, но мне например в голову не пришло.

Опыт, сын ошибок трудных. Вообще, грамотный подход к мастер-данным и НСИ в таких случаях - половина успеха. Если не больше.

А в чем различие двух рисунков, я не заметил

Его нет. Закоммитил по криворукости два раза. Как убрать лишнюю - не знаю.

про этот формат мы можем догадаться из постановки, хотя есть и формат xlsx

Да и тот, наверное, не формат, а целое семейство форматов (хотя бы по версиям "офиса"). Но на уровне архитектуры это не важно. Важно, что формат данных как-то определен.

Почему именно три, как определить, что трех достаточно

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

Какова его методологическая основа?

Увы.
Я знаю, как становятся архитекторами. Я не знаю, как научить человека быть архитектором. Как минимум, не задавался всерьез этим вопросом.

Очень мало знаком. В последний раз копался и программировал в 1С в 2000 году. Но чутье подсказывает, что единичное приложение (т.е. exe-файл со своим "обвесом") из набора 1С имеет только одну архитектуру. Решение на нем - другое дело.

Когда я вел речь о 1С (или иной платформе), то подразумевалось, что это только платформа (естественно она имеет свою архитектуру, а следовательно свои ограничения), но нужно естественно решение на ее основе. На само деле тут важно не то, как использовать 1С. А какова логика от платформонезависимой архитектуры (тоже вопрос как ее получать) к платформозависимой.

Форматно-логический контроль.

Впервые слышу, хотя понятно.

И остальное в ключе "не следует из постановки".

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

Я и не спорю. Все, что сейчас есть в ИТ (ну или многое) постигается путем передачи знания от мастера к подмастерью. Потому для начала хотелось бы научить формальным логическим выводам, правилам перехода, методикам.
Конечно, я согласен на ошибках учаться. Но создать грамотную среду, найти нужное количество ошибкомеров, и что бы они были адекватны. Мне пока представляется это фантастической задачей.

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

Может дадите мне список пятка? Лучше в Иванове, кто согласиться со студентом возиться?

Опыт, сын ошибок трудных. Вообще, грамотный подход к мастер-данным и НСИ в таких случаях - половина успеха. Если не больше.

Что такое грамотный подходит к каким-то мастер-данным и НСИ?

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

Ясно, что у студента нет такого опыта, следовательно он должен отражаться в постановке. Мне кажется именно в этом трудность, но и важность. Отразить минимальные знания для того, чтобы следует определенным правилам, получить варианты решения. Естественно с помощью преподавателя. Но это нормальная практика.

Я знаю, как становятся архитекторами. Я не знаю, как научить человека быть архитектором. Как минимум, не задавался всерьез этим вопросом.

Я не ставлю задачу сделать студента архитектором, Вы правильно заметили - нужна практика и немалая. Но мы должны познакомить студента практиками системного проектирования. Задача сложная, если она была простая, я не стал бы обращаться на форум.