Передо мной стоит следующая задача - разработать веб-ресурс для молодой организации. Таким образом, на начальном этапе следует составить контекстную диаграмму и диаграмму декомпозиции.
Так может надо начать с описания процесса разработки веб-ресурса? Составить хотя бы общее представление об организации процесса разработки?
Что будет начальным этапом, чем все завершится. У вас на диаграмме крайне мало ВХОДОВ, УПРАВЛЕНИЯ, но богато МЕХАНИЗМОВ, это главное в вашей задаче?
Если честно, не понял, что Вы имеете ввиду.
Смотрите у вашей разработки есть заказчик, этот заказчик выдвигает какие-то требования (то что вы ниже называли " пожелания, взгляды, просьбы"). Потому я и спросил, разве в ходе РАЗРАБОТКИ сайта не происходит ПРЕОБРАЗОВАНИЕ ВХОДА=требований заказчика в ВЫХОД= готовый сайт, соответствующий этим требованиям?
Иначе мне приходится читать вашу диаграмму так
на основании(под управлением) ТРЕБОВАНИЙ ЗАКАЗЧИКА функциональный блок РАЗРАБОТКА КОМ. САЙТА преобразует ЗАЯВКУ и ИНФОРМАЦИЮ О ПРЕДПРИЯТИИ в САЙТ и ДОГОВОР (например). Все верно? Требования не претерпевают изменения в ходе вашего процесса, они лишь управляют, ограничивают и т.п.?
В моем понимании ТЗ это некий набор правил, на которые следует опираться в обязательном порядке в процессе разработке, а требования заказчика - его пожелания, взгляды, просьбы, которые в зависимости от опыта разработчика могут быть в некотором смысле изменены для удовлетворительного результата.
Тогда вопрос, а откуда берется ТЗ из какого другого процесса, на основании чего создается ТЗ и какие такие правила оно включает?
Если все более менее правильно, как быть дальше?
Ничего собственно не изменилось, поскольку принципиально вы ничего не изменили. Нет точки зрения (неявно вы мне сигнализируете что она ваша, а вы кто? я же не знаю кто вы, 570326, что вы есть и какова ваша точка зрения.
Задача ваша разработать веб-ресурс (а почему не сайт?) - ну так разрабатывайте, какое отношение к этому имеете ваша контекстная диаграмма IDEF0? Ее цель какая? Зачем вы ее делаете?
С моей т.зр (например руководителя проекта) я хотел бы иметь модель типового процесса разработки коммерческого заказного сайта.
Я так понимаю, что этот процесс будет зависеть от методологии, общих требований к этому типовому процессу разработки, который я формулирую как руководитель проекта (бюджет, качество, сроки, люди), возможно и от законодательства, культуры, политики компании, но реально что влияет или нет на вашу модель зависит только от т. зрения и списка вопросов, на которые ваша модель должна отвечать. Потому максимум что можно дать вам в качестве рецензии - это проверка логики и синтаксиса.
А проверка простая.
1 вы смотрите выходы - это результат вашего функционального блока, анализируете всели придуманные вами выходы одного масштаба и действительно выходы
2 для каждого выхода смотрите что нужно для его получения, т.е. если ли входы
например
список паролей, как я представляю нет смысла писать пустой список паролей, но есть смысл иметь список сотрудников и их пароль на вход в ком.сайт (я уже не говорю о ролях, которые эти сотрудники выполняют внутри сайта), но откуда я возьму список сотрудников - я не вижу, если он в ТЗ, то почему ТЗ не на входе? ведь список сотрудников в ТЗ преобразуется в список сотрудников с паролями, а известно что управление не превращается в выход, оно инициирует, управляет, ограничивает, но не превращается в выход. Уловили идею?
Помощь с диаграммой декомпозиции