Cтраница 3
Обладая средствами документирования транзакций, программ, отчетов и традиционных файлов, СССД может способствовать разработке прикладных программ. Требования пользователей, накопленные на предшествующих стадиях, могут быть переведены на язык технических решений и введены в СССД. Затем метаданные, хранимые в СССД, с помощью имеющихся в составе этой системы средств генерации метаданных преобразуются в описания файлов на Коболе. Описание логики программ может быть полезно при подготовке первой редакции руководства для пользователя. Таковы лишь некоторые преимущества, которые может дать применение СССД. [31]
Первый шаг цикла проектирования системы включает определение набора требований пользователей и построение функциональной спецификации, вытекающей из требований пользователей. Требования пользователей определяют, что пользователь хочет от системы и что она должна делать. Хорошие системные спецификации определяют функции, выполняемые системой для пользователя после завершения проектирования, уточняя таким образом, насколько система соответствует требованиям пользователя. Они включают описания форматов как на входе, так и на выходе, а также внешние условия, управляющие действиями системы. Функциональная спецификация и требования пользователей являются критериями оценки функциональных характеристик системы после завершения проектирования. [32]
Требования пользователей определяют, что хочет или в чем нуждается пользователь или потребитель. Требования пользователя могут быть получены во время встреч с пользователем или покупателем с целью выявления его нужд и определения того, что пользователь хочет от системы. Другой подход используется при планировании ассортимента изделий, когда требования пользователей могут быть определены путем изучения рынка сбыта на основе спроса покупателей. Действительно, исследование конкуренции на рынке сбыта помогает определить, что будет и что не будет пользоваться спросом на рынке. [33]
В ходе фазового обзора III группа поддержки рассматривает внешнюю спецификацию изделия с точки зрения ее совместимости с существующими требованиями пользователя. Если требования пользователя изменились таким образом, что группа разработки не может их учесть без внесения существенных изменений в проект, то группа поддержки должна оценить ситуацию и либо поднять вопрос о пересмотре соглашения о требованиях, либо предложить компромиссное решение, не нарушающее требований внешней спецификации. В этот же период группа поддержки пересматривает извещения о календарных сроках и распределение бюджета и предлагает внести изменения в эти документы. [34]
При синтезе СОД РВ с приоритетным обслуживанием заявок необходимо учитывать многообразие входных потоков заявок различных типов, характеризующихся различной интенсивностью поступлений и приоритетностью обслуживания. Кроме того, требования пользователей на время обслуживания заявок значительно жестче по сравнению с первым классом СОД РВ, что требует размещения в оперативной памяти ряда программных процедур и данных, необходимых для обслуживания отдельных заявок. Взаимосвязи между заявками по составу решаемых задач в таких системах, как правило, весьма существенны. Повышение эффективности решения задач данного класса осуществляется, в основном, за счет сокращения числа и времени обмена между уровнями памяти при обслуживании заявок. Решение задач синтеза оптимальных СОД РВ с многопроцессорным обслуживанием предполагает сокращение не только времени обмена между уровнями памяти, но и среднего процессорного времени решения задач за счет параллельной реализации процедур, модулей или заявок в целом. [35]
ПС требуются заметные усилия и значительные дополнительные затраты. Во-вторых, поскольку требования пользователей к прикладным ПС в процессе кх эксплуатации меняются, они должны постоянно дорабатываться. Затраты на доработку или на поддержку ПС довольно значительны. Так, по некоторым оценкам, разработчики - поставщики ПС несут расходы по поддержке ПС в течение срока их эксплуатации у потребителей, равные 200 % их первоначальной стоимости. Если ПС разрабатываются для собственных нужд, то затраты на их поддержку составляют 30 - 40 % бюджета разработчика, а общая стоимость ПС - 350 - 450 % первоначальной цены. Затраты на поддержку коммерческих ПС обычно включаются в их стоимость. [36]
Рассматриваемые информационные системы проводят диалог с пользователем, во время которого постепенно собирают всю информацию, нужную для составления новой программы. При этом системы выявляют требования пользователя, которые противоречат друг другу, определяют неполноту даваемой информации. Диалог продолжается до тех пор, пока постановка задачи станет однозначной, ясной. Тогда автоматизированная система программирования, используя один из языков, понимаемый машиной, составляет искомую программу ее работы. [37]
Конечно, нужно прочитать всю документации по унаследованной системе и любую дру1ую пользовательскую документацию. Эти сведения часто указывают на требования пользователей, не упомянутые в других местах. [38]
В системе должны инкапсулироваться не только требования пользователей, но и возможность работы в реальном мире. Именно на этом этапе нужно задействовать квалификацию и талант администратора базы данных. Если в организации есть знающий свое дело администратор базы данных, можно изгнать всех консультантов и сэкономить значительные средства. [39]
Теперь мы готовы приступить к более детальному описанию цикла проектирования системы. В этой главе мы обсудим, как выявить требования пользователей, и покажем, как на основе этих требований определить функциональную спецификацию системы. Требования пользователей определяют, что пользователь хочет от системы, а функциональная спецификация фиксирует, что система должна делать и как она взаимодействует с окружением. Как только функциональная спецификация определена, она используется вместе с требованиями пользователей в качестве основы для проектирования, реализации и развития, системы. По этой причине важно, чтобы как требования пользователей, так и функциональная спецификация были не только полными и точными, но также четкими и легко усваиваемыми. [40]
Управляющие программы имеют модульную структуру. В процессе генерации они настраиваются на конфигурацию сети телеобработки и требования пользователя. Для описания сети телеобработки используется специальный набор макрокоманд. Генерация осуществляется в два этапа с использованием ассемблера ПТД и редактора связи. Программа-загрузчик предназначена для загрузки программы управления из дискового накопителя в память ПТД. Программа динамической распечатки содержимого памяти ПТД позволяет отображать определенные области памяти ПТД без прерывания работы управляющей программы. Независимая программа распечатки памяти ПТД служит для отображения всей памяти ПТД с приостановкой работы управляющей программы. Программа применяется чаще всего в случае неправильной работы ПТД. [41]
Накапливаемые страницы отчетов следует проанализировать. Каждый документ должен быть прочитан и из него выделены те требования пользователя, которые подвергнутся дальнейшей обработке. [42]
Поставщики вычислительной техники обычно отказываются давать какие-либо оценки надежности программного обеспечения и по числу ошибок, с которыми, возможно, столкнется пользователь и по возможному их влинянию на функционирование всей системы. Такая позиция совершенно естественна, поскольку невозможно предвидеть и заранее удовлетворить все требования пользователя или дать гарантии, что не существует ошибок, приводящих к отказу всей системы. Кроме того, те же производители часто готовы оценивать надежность оборудования, обычно игнорируя многочисленные сложности, о которых уже говорилось в нашей книге, и, сталкиваясь с ошибками проектирования, знают, какие усовершенствования следует разработать и внести в конструкцию с тем, чтобы обеспечить практическое достижение предсказанной надежности. Что касается программного обеспечения, большинство ошибок в котором считается ошибками проектирования, то пользователи, встречающиеся с отказами относительно высокого уровня, обычно получают соответствующую помощь, а те, кто в подобных случаях выражет свое недовольство особенно сильно, имеют даже больше. В конце концов все-таки достигается приемлемый уровень надежности. [43]
Кроссовые соединения реализуются с помощью специальных распределительных устройств. Кроссовая коммутация, на базе которой строится сеть некоммутируемых каналов, широко применяется в системах, где требования пользователей высоки и они не могут быть выполнены при применении оперативной коммутации. Основным недостатком кроссовой коммутации является неэффективное использование пропускной способности каналов связи и производительности оборудования. [44]
Теперь мы готовы приступить к более детальному описанию цикла проектирования системы. В этой главе мы обсудим, как выявить требования пользователей, и покажем, как на основе этих требований определить функциональную спецификацию системы. Требования пользователей определяют, что пользователь хочет от системы, а функциональная спецификация фиксирует, что система должна делать и как она взаимодействует с окружением. Как только функциональная спецификация определена, она используется вместе с требованиями пользователей в качестве основы для проектирования, реализации и развития, системы. По этой причине важно, чтобы как требования пользователей, так и функциональная спецификация были не только полными и точными, но также четкими и легко усваиваемыми. [45]