Служба маркетинга на каждый продукт, который, по ее мнению, следует поставить на рынок, составляет спецификацию требований покупателя и направляет руководству для предварительного одобрения. Затем спецификация передается в производственный отдел, где определяются возможности по выпуску данной продукции исходя из существующих производственных мощностей, наличия оборудования, квалификации и опыта работающих, а также с учетом потребностей в сырье и материалах. Заключение производственной службы направляется в плановый, финансовый и маркетинговый отделы предприятия, где проводится расчет издержек производства, цены, расходов на проведение рекламы и стимулирования продаж, на транспорт и т.д. Конечным итогом работы является составление плана выпуска продукции (объем, ассортимент и сроки поставки) и обеспечение производства материальными и другими ресурсами. Кроме того, в случае необходимости составляется план исследований и разработок для создания новых или модификации существующих изделий. [c.612]
Результатами работ на этой стадии являются функциональная и информационная модели организации и спецификации требований к предполагаемой системе, служащие в качестве исходных данных для проектирования системы. Желательно, чтобы функциональная и информационная модели и спецификации требований были выполнены с помощью формализованных методов их описания, например с использованием средств описания моделей в известных методологиях структурного или объектно-ориентированного проектирования и языков спецификаций. В этом случае в ТЗ, разрабатываемом по результатам стадии предпроектного обследования, должно быть указание на имеющиеся исходные данные и средства описания исходных данных. Ссылки в ТЗ на документы, определяющие выбранные средства описания исходных данных, — часть профиля инструментальной среды, поддерживающей основные процессы проектирование, разработку, сопровождение и развитие прикладного программного обеспечения ИС. [c.79]
На стадии стратегического планирования и анализа требований уточняются исходные данные и разрабатываются спецификации требований к прикладному программному обеспечению и к среде. Эти спецификации должны позволять уточнить первичные функциональные профили ИС, заданные в ТЗ, дополняя их стандартами, применение которых потребуется на стадии проектирования. Такие дополнения, в частности, могут возникать в связи с принятием принципиальных решений по структуре прикладного ПО, архитектуре среды распределенной обработки данных, распределению функций защиты информации между прикладным программным обеспечением и средой ИС для обеспечения заданной категории информационной безопасности, выбору инструментальных средств проектирования и программирования. Принимаемые на этой стадии решения исходят из альтернативного выбора методологии и принципов построения ИС между функционально-модульным и объектным подходами. В плане создания ИС, разрабатываемом на этой стадии, учитываются работы, связанные с построением и оформлением функциональных профилей ИС [c.80]
Составление концептуального проекта, или эскиза, будущего продукта, возможно, является наиболее творческой стадией процесса. Цель — выработать ряд возможных подходов к осуществлению заявленных в спецификации требований. Как и мозговую атаку, составление концепций лучше всего проводить в более-менее спокойной атмосфере, без лишней критики, и только по окончании оценивать осуществимость проектов. Лучший из них переходит на стадию разработки рабочего проекта, когда составляются чертежи, перечни деталей и комплектующих, технологические процессы, технические условия на проведение испытаний и так далее. [c.56]
Архитектор — это лицо или организация, имеющие право профессионально, на основе соответствующим образом оформленной лицензии, выполнять работы по созданию проектно-сметной документации, спецификаций, требований к проведению торгов и даже общее управление проектом. [c.31]
Тип соответствия. 1. Модель соответствия один к одному (каталожная модель). Каждой спецификации требования в функциональном пространстве будет дано какое-то решение в опознавательном пространстве с точным соответствием. Проблема проектирования сводится к проблеме поиска данных. Это значит, что никакого артефакта не будет создано в ходе проектирования, который не существовал в прошлом. 2. Расчетная модель. Если допустить аппроксимацию в опознавательном пространстве, полагая множество элементов опознавательного признака конечным. и каждый элемент выразить числом, то возможно представить функцию от признаков. 3. Порождающая модель. Если существует ряд правил, которые создают решение в значениях опознавательного признака, давая спецификацию в значениях функции, то проект детерминирован порождающим правилом. [c.28]
Программа считается корректной, если она выполняет запланированные действия и не имеет побочных эффектов. Корректность представляет собой достаточно узкое понятие, так как ее полная проверка для больших программных систем практически не выполнима. Корректность базируется на тщательной спецификации требований пользователя. Возможна ситуация, когда некоторая программа является корректной с точки зрения разработчика, но не корректной с точки зрения пользователя, так как предмет расхождений в оценке не был точно специфицирован в требованиях к программе. [c.3]
При спецификации требований по представлению данных выделяются требования по точности представления, включающей математическую точность при вводе, обработке и выводе ограничения по точности передачи информации по каналам связи и т. д. Требования к представлению данных должны быть сформулированы с учетом таких ограничений, как время ответа, время обмена данными, время перемещения и передачи и время ввода-вывода. [c.194]
Декларируя одни или не признавая вовсе определенные принципы, конкретный субъект часто придерживается других, достаточно предсказуемых для него действий, что в конечном счете также становится практическим проявлением принципов прикладной организации. Именно поэтому практика реально воспринимаемых и осуществляющихся принципов привлекает постоянное внимание исследователей как наиболее полная и детерминированная спецификация требований к содержанию и ожиданий осуществления той или иной организации. [c.134]
Спецификация требований включает разработку и описание характеристик и количества продукта или услуги, которые необходимы. Это может быть сделано точным выбором торговой марки (например марки моторного топлива). С другой стороны, может понадобиться анализ требований, и спецификация будет разработана на основе этого анализа. Этому процессу соответствует термин проектирование стоимости . Если в этот процесс возможно вовлечение продавца, то он [c.155]
Воздействие закупочных операций на работу компании можно выявить благодаря трем стратегическим функциям закупки рациональности, развитию и структурированию. Функция рациональности охватывает многочисленные повседневные действия, предпринимаемые для изменения структуры затрат. Можно выделить три типа рациональности. Первый касается спецификации требований к предмету или продукту, который будет куплен. Это важнейший момент, требующий решения, следует ли изготовить нужный продукт на своих мощностях или купить его у внешних поставщиков (решения сделать или купить ), а также решений относительно конструкции или проекта продукта. Эффективность этого процесса значительно возрастет, если закупки будут осуществляться согласованно с исследовательским, проектным и производственным отделами, а также если закупщики будут иметь надежную информацию о возможностях и способностях различных поставщиков. Одна из методик, применяемых для этого, называется анализом стоимости ее задача состоит в том, чтобы снизить затраты при сохранении необходимых уровней доступности и надежности продукта (см. РАЗРАБОТКА НОВЫХ ТОВАРОВ ТОВАРНАЯ ПОЛИТИКА). [c.167]
Иногда существуют соответствующие национальные стандарты спецификаций (например, британские стандарты спецификации), на которые можно ссылаться при составлении спецификации требований. Имеется также множество спецификаций, разработанных официальными органами, включая военные организации. [c.157]
В основе различных методологий моделирования проблемных областей ЭИС лежат принципы последовательной детализации абстрактных категорий. Обычно модели строятся на трех уровнях на внешнем уровне (определении требований,), на концептуальном уровне (спецификации требований) и внутреннем уровне (реализации требований). Так, на внешнем уровне модель отвечает на вопрос, что должна делать система, то есть определяется состав основных компонентов системы объектов, функций, событий, организационных единиц, технических средств. На концептуальном уровне модель отвечает на вопрос как должна функционировать система Иначе говоря, определяется характер взаимодействия компонентов системы одного и разных типов. На внутреннем уровне модель отвечает на вопрос с помощью каких программно-технических средств реализуются требования к системе С позиции жизненного цикла ЭИС описанные уровни моделей соответственно строятся на этапах анализа требований, логического (технического) и физического (рабочего) проектирования. [c.277]
В первом варианте создание системы-прототипа используется для лучшей спецификации требований к разработке ЭИС, после разработки которых сам прототип оказывается ненужным. В этом случае традиционно разрабатывается Постановка задачи , документация которой является спецификацией системы-прототипа. После демонстрации пользователю и доработки [c.380]
Второй вариант предполагает итерационное развитие системы-прототипа в готовый для эксплуатации программный продукт. Итерации разработки системы-прототипа включают создание/модификацию системы-прототипа, ее демонстрацию пользователю и согласование, разработку новых спецификаций-требований к системе, новую модификацию и т.д., пока не будет создано готовое приложение. Документацию компонентов системы-прототипа непосредственно составляют спецификации, которые являются требованиями к программной реализации системы и определяют характер взаимоотношений с заказчиком на этапе сдачи готовой системы. Технологическая сеть проектирования данного варианта на стадии техно-рабочего проектирования ЭИС представлена на рис. 13.29. [c.382]
Д1 - техническое Задание на разработку Д2 - описания предметной области U1 - универсум средств быстрой разработки приложений G1 - приложение-прототип Д4 - результаты работы приложения-прототипа Д5 - замечания и уточненные требования к ЭИС G2 - доработанный прототип Д6 - новые спецификации-требования G3 - готовое приложение [c.383]
Д5) и происходят доработка прототипа (преобразователь ПЗ) и разработка новых спецификаций-требований (Д6) (преобразователь П4) либо система-прототип полностью удовлетворяет требованиям заказчика, и она документируется (преобразователь П5) и сдается в виде готового программного приложения (G3) с соответствующей документацией (Д7). [c.383]
Решение первой проблемы осуществляется на базе подхода, который называется управление базовой конфигурацией . Суть его заключается в четком определении требований к системе с учетом тенденций развития объекта управления и в обеспечении соответствия между проектом и спецификациями требований к нему. [c.485]
Гост 19.202 - 78. Единая система программной документации Спецификация. Требования к содержанию и оформлению. - М. Изд.-во стандартов, 1994. [c.499]
Если структура спецификации требований сформирована, то становится достаточно легко определить, где требования уже сформулированы, а где в структуре (в документе) пока еще остаются незаполненные места. Такие дыры можно легко найти и принять меры к их устранению. [c.187]
Анализ требований. Цель этого этапа состоит з проверке полноты и непротиворечивости спецификации требований. Далее строится П-модель информационной системы. На этом этапе может быть разработан прототип графического интерфейса пользователя. Результатом этапа является П-модель информационной системы, включающая прецеденты, субъекты и описание интерфейсов конечного пользователя. [c.204]
В анализе требований участвуют следующие объекты бизнес-системы Заказчик Продукта, Аналитик, Список Требований, Спецификация Требований и П-модель (рис. 8.4). Заказчик Продукта отвечает за инициирование разработки в соответствии со Списком Требований. Анализ требований имеет итеративный характер. Он описывается следующим образом. [c.212]
Заказчик Продукта "инициирует" Аналитика сформировать Спецификацию Требований на основе Списка Требований. [c.213]
Аналитик, используя информацию о доступных ресурсах и приоритетах, указанных в Списке Требований, разрабатывает Спецификацию Требований для текущей версии. [c.213]
Аналитик выделяет прецеденты исходя из потребностей субъектов и Спецификации Требований. При необходимости он структурирует П-модель с помощью отношений использования и расширения (см. разд. 5.5). [c.213]
После того как Аналитик строит первую версию П-модели, инициируется Проектировщик Идеальной Модели. Входом для него являются Спецификации Требований и П-модель. [c.215]
ГОСТ 19.202-78 ЕСПД. Спецификация. Требования к содержанию и оформлению. [c.382]
Система определения показателей качества ПС — основа разработки и применения спецификаций требований к разрабатываемым ПС. Порядок установления требований к ПС определен стандартом США1. [c.363]
ЗАКАЗ-СПЕЦИФИКАЦИЯ — требование потребителя к поставщику, определяющее конкретный ассортимент продукции, к-рая подлежит отгрузке в соответствии с заключенным договором и в рамках обусловленного объема поставки по определенному виду или номенклатурной группе продукции. 3.-с. составляется на основе предварительного уточнения потребности заказчика в материалах по развернутому ассортименту, т. е. по сортам, маркам, типам, размерам, артикулам и прочим признакам, характеризующим особенности продукции в пределах каждой номенклатурной группы п объема выделенных фондов по плану снабжения для данного предприятия. Такая работа но специфицированию фондов снабжения должна базироваться на уточненной программе пропз-ва (или выполнения строительных работ) и обычно ложится в основу составления квартальных оперативно-заготовительных планов снабжения предприятии. При этом учитываются ожидаемые к началу квартала размеры запасов по развернутому ассортименту и планируемый уровень этих запасов к концу квартала. [c.248]
Замечание 2. В данных вьппе определениях не оговаривались "балансовые" или другие ограничения на портфель ценных бумаг. Одним из обычных ограничений такого типа является, например, условие "самофинан-сируемости" (см. (13) в предыдущем параграфе). Разумеется, при конкретных рассмотрениях необходима спецификация требований на "допустимые" стратегии тт. [c.18]
Покупательское решение организации можно рассматривать как процесс, происходящий во времени. В нем есть несколько ключевых стадий. Однако не все из них обязательно присутствуют в каждой ситуации. Процесс может быть длинным в одних ситуациях и относительно коротким в других. Для отражения различных стадий можно предложить ряд разнообразных моделей, каждая из которых по существу состоит из одних и тех же элементов идентификация потребности, спецификация требований, поиск поставщиков, выбор поставщика, заказ на поставку, оценка после покупки и управление поставщиками (Moller, 1985). [c.154]
Проекты, связанные со строительством, - это еще один пример работ, которые должны быть описаны с помощью спецификации. Все строительные подрядчики с любой репутацией работают с использованием подробных спецификаций. Требования законодательных структур лвляк УГСЯ одной из причин для документирования спецификаций, описываюшихвыбор места строительства для здания, его расположение, цели использования, способы эвакуации в случае пожара, внешний вид здания и многие другие факторы. Без сомнения, есть много деталей, касающихся сооружения, которые могут существенно повлиять на его стоимость, включая, например, стиль внутренней отделки, качество гарнитуры и встроенного оборудования, стандарты по освещенности и кондиционирование воздуха. [c.16]
Наибольшая потребность в использовании ASE-систем испытывается на начальных этапах разработки, а именно на этапах анализа и спецификации требований к ЭИС, Это объясняется тем, что цена ошибок, допущенных на начальных этапах, на несколько порядков превышает цену ошибок, выявленных на более поздних этапах разработки. [c.323]
Мразработка соэи - R (Разработка экономической системы), г (СОЭИ Разработчики СОЭИ), е (Организация и планирование разработки Спецификация требований Логическое проектирование Физическое проектирование Программная реализация проекта) [c.136]
Манкета проектных спецификаций — с (Спецификация требований), f (Информационная среда Функциональная среда Организационно-техническая среда Программно-алгоритмическая среда) [c.137]
Манализ спецификаций = п (Спецификация требований), г (Спецификация), е (Анализ полноты описания Анализ непротиворечивости описания Анализ информационной среды Анализ программно-алгоритмической среды Анализ технологической среды Анализ организационно-технической среды Анализ функциональной среды Динамический анализ) [c.137]
Мдокументирование проекта = п (Спецификация требований), г (Документ Техническое задание Терминологический словарь Словарь функций), е (Технико-экономическое обоснование Подготовка нерегламентированного документа) [c.137]
Гипертекстовая модель поведения проектировщика системы обработки экономической информации, включающая схемы работ на этапе организации и планирования, на этапе спецификации требований, на этапах логической, физической и программной реализации проекта, позволяет выбирать нужную последовательность действий проектировщика в зависимости от условий процесса разработки и особенностей СОЭИ. [c.168]