@Bubler

Суть вопроса такая: Мне требуется составить ТЗ на разработку приложения следующего функционала:

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

Заранее спасибо за помощь.

0

@Savvy

Bubler, если во главу угла ставится именно быстродействие, то оптимальный вариант это UI на C#, а вся логика в виде dll на С++ (в заивисмости от опыта с многопоточностью надо будет повозится). Статистику в БД однозначно, можно юзать ADO.NET, насколько я понимаю данные от сборок будут подыматься на уровень UI, так что не критично будет где-то сунуть dataprovider для пересчета и обновления статистики.

Итого я вижу решение так:
UI - C# (WinForms\WPF)
DB - ADO.NET, T-SQL, C#
Data Processing - C++ + Multithreading

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

1

@bumbaram

WCF - в качестве сервиса. Вполне может дергать библиотеки написанные на С++ для увеличения производительности критичных мест.
Silverlight - в качестве удобного графического интерфейса.
Собственно львинная доля на C#, возможно немного C++

ps а какие вы языки хотели увидеть, создавая тему в разделе "C# для начинающих"?

1

@CheshireCat

Стоп!
Так тебе нужна консультация по разработке ТЗ или по разработке приложения? Это - разные вещи.

В ТЗ вообще нецелесообразно указывать какие-то технологии или языки программирования. Это - реализация, это остается на усмотрение разработчика. Мухи - отдельно, котлеты - отдельно :-)

В ТЗ должны быть указаны: назначение и область применения изделия, ключевые функциональные и нефункциональные требования к разрабатываемому изделию (в данном случае - программе), перечень отчетных материалов и порядок контроля и приемки работы. Все. Почитай ГОСТы (19.201, 34-201 и другие, все гуглится) - там содержание ТЗ описано хорошо.

0

@Bubler

Дело в том, что кроме самого ТЗ мне надо дать рекомендации для подбора персонала. Поэтому надо определиться с требованиями к кандидату.

0

@CheshireCat

Рекомендации по подбору персонала простые: на данном этапе тебе нужны аналитик и архитектор. (Это помимо собственно менеджера aka руководителя проекта.) В маленьких проектах/командах эти роли (менеджера, аналитика и архитектора) может, в принципе, выполнять один человек.

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

Стоит ли бежать впереди паровоза?
На тебя что - сильно давит руководство, требуя "прямо здесь и сейчас! а желательно еще вчера!" ?
Календарный план (график) разработки есть? Насколько подробный?

0

@Bubler

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

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

0

@Bubler

Savvy,
bumbaram, Спасибо за помощь


Я ее тут не создавал, ее сюда перенес модератор. И как оказалось не зря. =)

0

@Noob.net

Все же я бы не советовал дергать с++,если с ним не знаком
Пиши все на родном шарпе(если так и есть).

А насчет быстродействия,если более-менее техника "человек-придира без очков не заметит"

0

@CheshireCat

Так.

1. Ну, вот эти книжки тебе помогут сориентироваться, как управлять проектом и как управлять требованиями (а требования - это критически важная вещь! "Провал проекта" происходит в 90% случаев из-за несоответствия полученного продукта фактическим требованиям Заказчика):

Разработка:
Вигерс Карл Разработка требований к программному обеспечению.pdf
Bass and Clements Software Architecture in Practice 2nd ed.chm
Ларман Крэг Применение UML и шаблонов проектирования.djvu

Управление:
Панкаж Джалота Управление программным проектом на практике.djvu
Ройс Уолтер Управление проектами по созданию ПО.pdf
Фатрелл Управление программными проектами.djvu
Орлов Технологии разработки ПО.pdf
Архипенков Руководство командой разработчиков ПО.pdf
Брукс Фредерик Мифический человеко-месяц.pdf
ДеМарко Том Deadline.pdf
ДеМарко Том Вальсируя с медведями.pdf
ДеМарко Том Человеческий фактор.pdf
Йордон Эдвард Смертельный марш.pdf

(все гуглится, все есть в электронном виде)

2. Сосредоточься сейчас на анализе требований и разработке ТЗ (а тут ключевые документы для тебя - это ГОСТы 19 и 34 групп, или группы РВ 15). Хорошее толковое ТЗ - это 60% успеха разработки. И да, время на разработку ТЗ нужно закладывать в проект! ТЗ само по себе "из ниоткуда" волшебным образом не материализуется!

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

Не забудь про управление рисками в проекте. Составь план управления рисками и соответствующие сроки и затраты (на предупреждение риска и на минимизацию его последствий) тоже заложи в график.

2

@Bubler

Заметит. Речь идет о действительно больших объемах данных. Т.е. вычисления будут идти для одного пользователя от десятков секунд до единиц минут.

0

@bumbaram

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

0

@Bubler

CheshireCat, спасибо большое за советы. С чего из предложенной вами литературы посоветуете начать?

0

@Bubler

Нет, именно вычисления - обработка статистическими методами больших объемов данных. БД только для накопления результатов.

0

@CheshireCat

По требованиям - с Вигерса.
По управлению - с Джалота, в параллель можно читать Йордона и Брукса.
А вообще, оно все нужно... и много другое -тоже :-) но, к сожалению, в сутках всего 24 часа.....

1

@Bubler

CheshireCat, еще раз спасибо. Скачал, приступаю к изучению. =)

0