Определение спецификаций программны и аппаратных средств. [c.398]
Особо следует остановиться на этапе сопровождения ПО САПР, т. е. изменения ПО при сохранении его основных функций. Это такие работы, как перепроектирование небольших частей ПО (не более 50% общего объема закодированного ПО),, проектирование небольших интерфейсных программ и пакетов (не более 20%), модификации кода, документации или структуры базы данных программного изделия. Различают два главных вида сопровождения ПО — обновление, приводящее к изменению функциональной спецификации программного изделия, и исправление, не изменяющее функциональной спецификации (корректирование ошибок, адаптация к программному окружению и совершенствованию характеристик). [c.89]
Написание спецификации. Третий шаг трансляции (точка 3) связан с преобразованием целей во внутренние спецификации, содержащие точные описания поведения системы с точки зрения пользователя. В разработке ПО этот шаг трансляции является самым значительным. По объему и степени сложности ошибок, порождаемых на этом шаге трансляции, он занимает основное место во всем процессе разработки ПО. После написания внутренних спецификаций программное обеспечение можно проектировать, кодировать и отлаживать. Стадия проектирования является основной для планируемого уровня надежности системы. На этой стадии выбираются и реализуются в документации основные приемы обеспечения надежности за счет схемных решений и за счет выбора оптимальных способов организации будущей эксплуатации и применения системы. [c.51]
Программа (G) — это некоторое проектное решение по реализации заданной функции управления объектом или по обработке данных, записанное в виде функциональных спецификаций, программных спецификаций, схемы алгоритма, алгоритма на одном из алгоритмических языков или в виде машинного алгоритма. В процессе создания СМОД программы как объекты разработки могут иметь различные состояния и, следовательно, различные формы документального отображения этих состояний (функциональные спецификации, программные спецификации, схемы алгоритмов, алгоритмы, записанные на одном из алгоритмических языков на специальных бланках, и др.). Документально зафиксированные состояния программ призваны обеспечить взаимосвязь между различными ТО проектирования при создании программного обеспечения СМОД. [c.16]
На следующем этапе осуществляется физическая интерпретация данных анализа с целью создания схем вычислительного процесса при выполнении требований его оптимизации, конструирования структур данных на логическом и физическом уровнях, генерации и порождения программ, реализующих обработку данных в создаваемой системе. В соответствии с результатами анализа проводится выбор конфигурации комплекса технических средств, которые будут использованы в создаваемой системе. В результате-этого этапа формируются спецификации программных модулей, определяется структура используемой памяти и проводится подготовка к физическому формированию создаваемой системы обработки данных. [c.52]
На рассмотрение, переработку и утверждение соглашения о требованиях может уйти немало времени. Хороший руководитель проекта совмещает эту деятельность с продолжением разработки в тех масштабах, которые позволяют ему имеющиеся ресурсы. Это совмещение следует поощрять, например, путем выделения средств на разработку спецификаций программного изделия в надежде на то, что соглашение о требованиях будет утверждено в первоначальном виде или претерпит лишь незначительные изменения, допустимые планом. [c.105]
С учетом четкого различия между внешним и внутренним проектами следует составлять внешние и внутренние спецификации программного изделия. При этом необходимо избегать появления общих мест в разных документах. Форма внешних спецификаций, описанных в разд. 15.1, представляет собой прямую декомпозицию [c.107]
Испытания класса В представляют собой независимую проверку программного изделия на соответствие спецификациям, в -частности соглашению о требованиях и внешним спецификациям. Программное изделие считается готовым к проведению испытаний класса В после успешного завершения приемочных испытаний. Группа разработки составляет отчет об испытаниях класса А, подытоживающий результаты этих испытаний, в том числе приемочных, и свидетельствующий о готовности программного изделия к испытаниям класса В. [c.114]
Детальное (рабочее) проектирование, включающее разработку спецификаций каждого компонента и, прежде всего, создание или привязку программных средств, интерфейсов между компонентами, разработку плана интеграции компонентов, формирование обширных инструкционных материалов. [c.70]
Первая стадия — формирование общей структурной схемы. К принципиальным характеристикам организационной структуры, которые определяются на этой стадии, можно отнести цели производственно-хозяйственной системы и проблемы, подлежащие решению общую спецификацию функциональных и программно-целевых подсистем, обеспечивающих их достижение число уровней в системе управления степень централизации и децентрализации полномочий и ответственности на разных уровнях основные формы взаимоотношения данной организации с внешней средой требования к экономическому механизму, формам обработки информации, кадровому обеспечению организационной системы. Основополагающее значение для общей структурной схемы имеет разработанная руководством компании стратегия развития организации. В одном случае это может быть ориентация, например, на удовлетворение потребностей клиентов, в другом — на изготовление продукции. Применительно к этим двум крайним случаям (на практике существует много промежуточных вариантов) различия в организационной структуре управления могут быть существенными (рис. 10.2). [c.131]
Для трейдеров, далеких от программирования, которые не владеют языком С или каким-то другим языком программирования было специально разработано дружественное по отношению к пользователю программное обеспечение. Эти программы позволяют трейдеру описывать и тестировать торговые идеи, не имея опыта программирования. Это не говорит о том, что от неправильно определенной системы можно ожидать правильных результатов. Тем не менее, эти программы на самом деле имеют несколько встроенных функций и операций, существенным образом облегчающих спецификацию торговой системы. [c.18]
Согласно этому определению открытая спецификация не зависит от конкретной технологии, т.е. не зависит от конкретных технических и программных средств или продуктов отдельных производителей. Открытая спецификация одинаково доступна любой заинтересованной стороне. Более того, открытая спецификация находится под контролем общественного мнения, поэтому заинтересованные стороны могут принимать участие в ее развитии. [c.39]
Профиль АРР ориентирован на менеджеров и руководителей проектов, несущих ответственность за приобретение, развитие и эксплуатацию информационных систем, поддерживаемых неоднородными аппаратными, программными и коммуникационными средами. Прикладные программы в среде OSE могут включать информационные системы административного управления, встроенные системы, системы реального времени, системы обработки транзакций, системы баз данных, географические информационные системы или другие системы, в которых могут применяться рекомендуемые спецификации. Поскольку описываемые здесь спецификации по своему характеру сугубо технические, то по вопросам применимости каждой из них к конкретной задаче оптимизации пользователи должны консультироваться с соответствующими специалистами. [c.50]
Таким образом, профиль конкретной системы не является статичным, он развивается, конкретизируется (возможно, во взаимодействии с заказчиком) в процессе проектирования ИС и оформляется в составе документации проекта системы. В профиль конкретной системы включаются спецификации компонентов, разработанных в составе данного проекта, и спецификации использованных готовых программных и аппаратных средств, если эти средства не специфицированы соответствующими стандартами. После завершения проектирования и испытаний системы, в ходе которых проверяется ее соответствие профилю, профиль применяется как основной инструмент сопровождения системы при эксплуатации, модернизации и развитии. [c.71]
Результатами работ на этой стадии являются функциональная и информационная модели организации и спецификации требований к предполагаемой системе, служащие в качестве исходных данных для проектирования системы. Желательно, чтобы функциональная и информационная модели и спецификации требований были выполнены с помощью формализованных методов их описания, например с использованием средств описания моделей в известных методологиях структурного или объектно-ориентированного проектирования и языков спецификаций. В этом случае в ТЗ, разрабатываемом по результатам стадии предпроектного обследования, должно быть указание на имеющиеся исходные данные и средства описания исходных данных. Ссылки в ТЗ на документы, определяющие выбранные средства описания исходных данных, — часть профиля инструментальной среды, поддерживающей основные процессы проектирование, разработку, сопровождение и развитие прикладного программного обеспечения ИС. [c.79]
На стадии стратегического планирования и анализа требований уточняются исходные данные и разрабатываются спецификации требований к прикладному программному обеспечению и к среде. Эти спецификации должны позволять уточнить первичные функциональные профили ИС, заданные в ТЗ, дополняя их стандартами, применение которых потребуется на стадии проектирования. Такие дополнения, в частности, могут возникать в связи с принятием принципиальных решений по структуре прикладного ПО, архитектуре среды распределенной обработки данных, распределению функций защиты информации между прикладным программным обеспечением и средой ИС для обеспечения заданной категории информационной безопасности, выбору инструментальных средств проектирования и программирования. Принимаемые на этой стадии решения исходят из альтернативного выбора методологии и принципов построения ИС между функционально-модульным и объектным подходами. В плане создания ИС, разрабатываемом на этой стадии, учитываются работы, связанные с построением и оформлением функциональных профилей ИС [c.80]
Свойство — это любая отличающаяся от переменной характеристика, которая может быть однозначно описана в тексте или сопоставлена с воспроизводимым стандартом. Проверка свойств проста — да или нет либо характеристика соответствует спецификации, либо нет. Примерами свойств являются требование к комплекту программного обеспечения выполнять специальные функции, отсутствие ошибок в бланках о выплате страхового возмещения, напряжение переменного тока или направление вращения ручек. [c.495]
УМТСиК оформляет заявки на поставку МТР для капитального строительства, сформированные в программном комплексе, в виде сводно-заказных спецификаций (СЗС) в срок до 10 июня [c.149]
Технология последовательной разработки применяется для небольших приложений с жестко заданными требованиями, которые не изменяются в процессе создания системы. Это приложения типа подготовки отчетов по требуемой форме, ввода данных в БД по заданному шаблону, форме и т.п. Метод представляет собой строго последовательный процесс создания системы по этапам жизненного цикла программного обеспечения. Каждый этап завершается спецификацией для следующего этапа. [c.345]
Программа считается корректной, если она выполняет запланированные действия и не имеет побочных эффектов. Корректность представляет собой достаточно узкое понятие, так как ее полная проверка для больших программных систем практически не выполнима. Корректность базируется на тщательной спецификации требований пользователя. Возможна ситуация, когда некоторая программа является корректной с точки зрения разработчика, но не корректной с точки зрения пользователя, так как предмет расхождений в оценке не был точно специфицирован в требованиях к программе. [c.3]
Одно известное определение программной ошибки утверждает, что программная ошибка происходит тогда, когда программа работает не в соответствии со своими спецификациями. Это определение имеет один существенный недостаток однозначно предполагается, что спецификации корректны. Однако редко можно встретить явное подтверждение корректности спецификации, хотя опыт показывает, что одним из главных источников ошибок являются спецификации. Если программа работает не в соответствии с ее спецификациями, то это можно объяснить присутствием ошибки. Но если программа работает в соответствии со спецификациями, то нельзя утверждать, что ошибок в ней нет. [c.6]
Спецификация общего ПО. Решения, принимаемые разработчиком прикладных систем ПО, в значительной мере ограничиваются возможностями общего программного обеспечения. Разработчик должен взаимодействовать в вычислительной системе с языками общего назначения, пользуясь их средствами ввода-вывода и динамического распределения ресурсов. Незнание или неправильное толкование возможностей этих средств также может служить причиной возникновения ошибок (точка 8) [c.53]
Спецификация языков программирования. Написание программы обработки информации может быть выполнено на одном или нескольких языках программирования. Конечный продукт разработки — программа обработки информации — выражается оператором только одного языка. Неправильное использование языковых конструкций, синтаксиса и семантики языка (или языков) программирования может послужить серьезной причиной возникновения программных ошибок (точка 9) [c.53]
Ошибочные значения содержат константы и литералы. В разделе входные подобные ошибки встречаются во входных потоках информации пользователя и в файлах данных. Эти ошибки являются результатом несоответствия входных данных программным спецификациям. В разделе внутренние такие ошибки могут проявляться в виде констант или литералов, входящих в состав кода, инициализирующего некоторые вычисления. [c.61]
На стадии начального проектирования функциональные требования преобразуются в программные спецификации. Ошибки этой стадии будут классифицироваться в категории умственные. При внедрении имеют место ошибки, которые описываются также в категории умственные и механические. На стадии функционирования ошибки фиксируются не разработчиком, а пользователем. Источником ошибок является обработка редких комбинаций данных. [c.63]
Методы проведения работ на каждом из этапов в значительной мере определяют надежность разрабатываемого программного обеспечения. Например, начальный этап проектирования включает процессы формирования требований пользователя к системе, описание целей разрабатываемой системы и создание ее спецификаций. Целью проектирования на данном этапе является высокоуровневая проработка с определением интерфейса пользователя будущей системы ПО. [c.98]
Проверка внешних спецификаций. Рассмотренные до сих пор вопросы касались интерфейса пользователь — программное обеспечение . Дальнейшие действия по проектированию должны быть сосредоточены на внешней структуре ПО. По этой причине и вследствие трудностей, предварительно обсуждавшихся при выработке качественной внешней спецификации, проверка полноты и точности внешней спецификации является крайне важной. [c.120]
Документ программных спецификаций. Цель документа, содержащего программные спецификации,— определение требований для программистов, отражающих характеристики и условия работы в проектируемой машинной программе. Этот документ включает секции основной информации, требований, условий работы и проектируемых характеристик. [c.199]
Секция Спецификации и оценки содержит сведения о спецификациях (функциональных и программных), методах и ограничениях тестирования, критериях оценки и обработки данных тестирования [c.204]
Аналитический подход в первую очередь затрагивает тестирование и обоснование программ после того, как они написаны, чтобы повысить их надежность. Он включает традиционные методы отладки программ, средства доказательства правильности программ, различные средства автоматического тестирования. Конструктивный подход использует набор надежных программных средств для разработки надежного ПО, которые принято называть структурным программированием. Этот подход включает построение средств, использующих просмотр сверху вниз и формальные спецификации, и средства кодирования с применением простых управляющих структур. [c.260]
Разработка По достаточно сложный процесс и его поэтапное выполнение не всегда возможно. Появление новых требований в процессе разработки учитывается при планировании проекта в несколько итераций с использованием языка моделирования UML (Unified Modeling Language —унифицированный язык моделирования). Это визуальный язык моделирования общего назначения, который используется для спецификации, визуализации, конструирования и документирования программных систем. При этом проходится 4 фазы проекта начальная фаза, уточнение, конструирование и ввод в действие. [c.37]
В качестве методологической базы построения и применения профилей сложных распределенных ИС предлагается использовать ГОСТ Р ИСО/МЭК ТО 10000-1, 2-99 Информационная технология. Основы и таксономия профилей международных стандартов Часть 1 Общие положения и основы документирования Часть 2 Принципы и таксономия профилей взаимосвязи открытых систем Часть 3 Принципы и таксономия профилей среды открытой системы , определяющую основы и таксономию профилей среды открытых систем, предлагается использовать при построении и применении профилей ИС как документ прямого применения. Эталонная модель среды открытых систем (OSE/RM) определяет разделение любой информационной системы на приложения (прикладные программы и программные комплексы) и среду, в которой эти приложения функционируют. Между приложениями и средой определяются стандартизованные интерфейсы (Appli ation Program Interfa e — APT), являющиеся необходимой частью профилей любой открытой системы. Кроме того, в профилях ИС могут быть определены унифицированные интерфейсы взаимодействия прикладных программ (функциональных частей) между собой и як ерфейсы взаимодействия между компонентами среды ИС. В соответствии с определениями профиля и базовых стандартов, входящих в профиль, по ГОСТ Р ИСО/МЭК ТО 10000 спецификации выполняемых функций и интерфейсов взаимодействия могут быть оформлены как профиль каждого компонента системы. Таким образом, профили ИС как сложной системы с иерархической структурой могут включать в себя стандартизованные описания функций, выполняемых данной системой, и взаимодействия с внешней для нее средой, стандартизованные интерфейсы между приложениями и средой ИС и профили отдельных функциональных компонентов, входящих в систему. [c.67]
Разработка DFD начинается с построения диаграммы верхнего уровня, отражающей связи программной системы, представленной в виде единого процесса, с внешней средой. Декомпозиция процесса проводится до уровня, где фигурируют элементарные процессы, которые могут быть представлены одностранич-ными описаниями алгоритмов (мини-спецификациями) на языке программирования. [c.122]
Классические методы проектирования. Конец 70-х — начало 80-х годов — это время становления технологии интегрированных баз данных как одной из головных технологий в проектировании ИС. Был разработан и вошел в практику большой набор теоретически обоснованных методов проектирование концептуальных и логических схем БД, организация физической среды хранения данных, планирование путей доступа к данным и др. Развивались методы проектирования функций от методов формальной спецификации функций до структурного программирования и первых непроцедурных языков программирования четвертого поколения (4GL). Анализ функций (задач) предприятия также служил основой и в проектировании БД. Появились ASE-системы, ориентированные на формализацию информационных и функциональных требований к ИС и предназначенные для формального описания и бригадной разработки больших программных комплексов. [c.135]
ASE-репозитарий — база данных ASE-системы, в которой хранится проектная информация, представленная сложными взаимосвязанными данными — графическими диаграммами, программными спецификациями и т.п. [c.298]
Открытая спецификация [Open Spe ifi ation] — общедоступная спецификация, которая поддерживается открытым, гласным согласительным процессом, направленным на постоянную адаптацию новой технологии, и соответствует стандартам.-Открытая спецификация не зависит от конкретной технологии, т.е. не зависит от конкретных технических и программных средств или продуктов отдельных производителей. [c.333]
Написание компонентов ПО. В точке 4 обсуждаемой модели выполняется несколько шагов трансляции, начиная с трансляции внутреннего описания и кончая детальной разработкой необходимого набора программных операторов, обеспечивающих работу ПО в соответствии с заданными спецификациями. Этот этап работы реализует такие шаги, как трансляция внешнего описания проблемы в структуру компонентов ПО (модулей) и трансляция этих компонентов в описания структурного уровня, например блок-схемы процессов обработки информации. Именно в этой точке модели разработчик имеет дело с все возрастающим объемом информации, а отсюда и вероятность возникновения ошибок здесь достаточно высока. Основными задачами исследования надежности системы в это время являются задачи сравнительного анализа эффективности различных способов обеспечения надежности и выбор вариантов, обладающих заданной надежностью при учете реально существующих ограничений по различного рода ресурсам. Эти исследования могут проводиться на уровне моделей. Получение программы. Процесс последнего этапа разработки представляет собой трансляцию программных спецификаций в операторы языка программирования,. В силу формальности и рутинности выполняемой работы на этом этапе отмечается большое число ошибок, но эти ошибки, как правило, легко обнаруживаются и исправ- [c.51]
При этом во внимание принимаются компоненты, процессы и интерфейсы. Как правило, в результате проектирования получается набор программных спецификаций, которые затем используются в качестве входных относительно процесса реализации. На любом этапе разработки концепция разработки может изменяться, все больше отличаясь от первоначальной. В этой ситуации ошибками концептуализации являются неправильно сделанные вы-йЬды из спецификаций, а ошибками реализации являются Заработки, не соответствующие концепции. [c.65]
Связь с пользователем 101 Сложность 39 Совместимость 112 Сопровождаемость 109 Специфика торговли программным обеспечением 77 Спецификация [c.270]