авторефераты диссертаций БЕСПЛАТНАЯ БИБЛИОТЕКА РОССИИ

КОНФЕРЕНЦИИ, КНИГИ, ПОСОБИЯ, НАУЧНЫЕ ИЗДАНИЯ

<< ГЛАВНАЯ
АГРОИНЖЕНЕРИЯ
АСТРОНОМИЯ
БЕЗОПАСНОСТЬ
БИОЛОГИЯ
ЗЕМЛЯ
ИНФОРМАТИКА
ИСКУССТВОВЕДЕНИЕ
ИСТОРИЯ
КУЛЬТУРОЛОГИЯ
МАШИНОСТРОЕНИЕ
МЕДИЦИНА
МЕТАЛЛУРГИЯ
МЕХАНИКА
ПЕДАГОГИКА
ПОЛИТИКА
ПРИБОРОСТРОЕНИЕ
ПРОДОВОЛЬСТВИЕ
ПСИХОЛОГИЯ
РАДИОТЕХНИКА
СЕЛЬСКОЕ ХОЗЯЙСТВО
СОЦИОЛОГИЯ
СТРОИТЕЛЬСТВО
ТЕХНИЧЕСКИЕ НАУКИ
ТРАНСПОРТ
ФАРМАЦЕВТИКА
ФИЗИКА
ФИЗИОЛОГИЯ
ФИЛОЛОГИЯ
ФИЛОСОФИЯ
ХИМИЯ
ЭКОНОМИКА
ЭЛЕКТРОТЕХНИКА
ЭНЕРГЕТИКА
ЮРИСПРУДЕНЦИЯ
ЯЗЫКОЗНАНИЕ
РАЗНОЕ
КОНТАКТЫ


Pages:     | 1 | 2 || 4 | 5 |

«УДК 002.52/.54(075.8) ББК 32.81я73 МИНОБРНАУКИ РОССИИ ...»

-- [ Страница 3 ] --

Осуществляется научная и финансовая поддержка этого направления. В рамках программы «Научные исследования высшей школы по приоритетным направлениям науки и техники» с этого года открыто финансирование специальной подпрограммы «Управление качеством продукции и услуг систем менеджмента качества», где МГТУ «Станкин» является головной организацией. Однако, учитывая характер и значимость подготовки таких специалистов, необходимо консолидировать усилия. Финансовый, научный и организационный потенциал в Минобразования России, в Российской академии наук и, Минпромнауки России имеется. Примером тому может служить объединение усилий в лице образования и академической науки. Это МГТУ «Станкин» и Института конструкторско технологической информатики РАН. Другим примером может служить создание Государственного межведомственного научно-исследовательского и образовательного центра CALS-технологий, объединяющего усилия образования и производства в лице Минпромнауки России. Таким образом, Министерство образования открыто для подобного рода сотрудничества.

• Проблемы всеобъемлемости подготовки кадров Анализ внедрения CALS(ИПИ)-технологий на предприятиях позволяет сделать вывод, что необходимы специалисты, которые должны уметь разрабатывать такие системы. Их количество для РФ измеряется, по крайней мере, несколькими сотнями человек.

Во много раз больше требуется специалистов, которые будут заниматься внедрением CALS(ИПИ)-технологий на каждом предприятии. И, наконец, буквально каждый инженер должен стать квалифицированным пользователем та-кой системы и применять ее в своей деятельности. Поэтому проблема единого методического начала, создания государственных образовательных стандартов и программ, где должна быть определена не только специальность, но и соответствующие специализации. Опыт создания подобного рода «интегрированных» специальностей, если можно так сказать, в Министерстве образования есть. Например, относительно недавно была создана специальность в области управления качеством.

Научно-педагогические кадры • Проблемы сроков подготовки кадров С точки зрения сроков подготовки специалистов анализ сложившейся ситуации указывает на два важных фактора. Первый - это то, что сегодня у нас нет времени на ожидание выпуска первых специалистов — такие люди нужны на предприятиях уже сейчас, и потребность в них будет только возрастать. Второй - связан с постоянным и весьма бурным развитием самих CALS(ИПИ)-технологий и поддерживающих их программных продуктов.

Это означает, что знания, полученные специалистами, быстро устаревают и возникает потребность в их обновлении, т.е. в переподготовке специалистов, уже работающих на предприятиях. Отсюда возникает проблема непрерывного и дополнительного образования, которая полностью соответствует принятой в настоящее время в странах ЕС, а также в США и Канаде концепции, согласно которой каждый специалист должен регулярно пополнять свои знания.

• Очередные задачи Так в 2002 г. по НТП «Научные исследования высшей школы по приоритетным направлениям науки и техники» разработан государственный образовательный стандарт по двум новым специальностям «Автоматизированное управление жизненным циклом продукции (по отраслям)» и «Компьютерные системы управления качеством для автоматизированных производств (по отраслям)» в рамках направления подготовки дипломированного специалиста «Автоматизированные технологии и производства».

Действия, приводящие к выполнению проекта, потребность в которых выявляется в ходе планирования, могут быть типовыми бизнес-процессами (закупка комплектующих, разработка документации, производство). Такие бизнес-процессы часто выполняются по формальным схемам (моделям) [IDEF/0/3]. Исполнители (организации или сотрудники), действуя в соответствии с заданной технологией (моделью процесса), получают и выполняют задания, соответствующие структурным элементам бизнес-процесса (операциям). Автоматизация управления потоком таких заданий — функция технологии «workflow» (дословно с английского — «поток работ»).

Особую роль в их реализации сыграли и продолжают играть информационные технологии, развитие которых можно охарактеризовать таблицей 1.

Таблица Эволюция информационных технологий Годы Определения 1960 Автоматизация выполнения простейших функций 1970 Интеллектуальная направленность информационных технологий, развитие информационного моделирования, прогнозирования и управления 1980 Расширение областей применения информационных технологий, создание локальных сетей и электронных баз данных. Привлечение к использованию информационных технологий руководителей всех уровней управления 1990 Стремление к объединению информационных ресурсов и кооперации при создании информационных технологий;

совместное использование информации;

виртуальные предприятия В итоге информация стала основным товаром. Информацию, циркулирующую в системе информационной поддержки жизненного цикла изделия, можно условно разделить на три класса: данные о продукции (изделии);

данные о выполняемых процессах;

данные о ресурсах, требуемых для выполнения процессов. Под изделием (конечным) понимается комбинация материалов, предметов, программных и иных компонентов, готовых к использованию по назначению. Компоненты конечного изделия тоже являются изделиями.

Данные об изделии составляют основной объем информации в ИИС. Международные стандарты ИСО 10303 и ИСО 15384 регламентируют технологию представления данных об изделии и его компонентах на стадии проектирования и подготовки производства, стандарты ИЛП [DEF STAN 0060] — представление данных об изделии в контексте обеспечения эффективной эксплуатации, стандарты серии ИСО 9000 рассматривают данные о качестве изделий. Одним из ключевых понятий в проектировании является ресурс — совокупность материальных, финансовых, интеллектуальных или иных ценностей, используемых и расходуемых в ходе деятельности, связанной с разработкой, проектированием, производством или эксплуатацией изделия. Некоторые классификационные характеристики ресурсов приведены в таблице 2.

Таблица Классификационные характеристики ресурсов По типу физической По характеру расхода и По профилю По способу измерения природы возобновления доступности величины Материальный Не расходуемый Доступный Измеряемый в Финансовый (используемый) постоянно количественных Информационный Расходуемый, но Доступный в единицах Трудовой возобновляемый соответствии с Измеряемый в Временной Расходуемый расписанием логических единицах Энергетический безвозвратно (есть/нет) Другие Между ресурсами могут существовать отношения заменяемости, когда один ресурс может заменить другой, и взаимозаменяемости, когда ресурсы могут заменять друг друга.

Ресурсы могут быть простыми и составными и соответственно образовывать иерархические структуры. Структуры данных, описывающих ресурсы различного типа, регламентируются стандартом ИСО 15551.

Предпосылки создания CALS В течение многих десятков лет общепринятой формой представления результатов интеллектуальной деятельности людей и инструментом их информационного взаимодействия являлась бумажная документация. Ее созданием были заняты(и заняты по сей день) миллионы инженеров, техников, служащих промышленных предприятий, государственных учреждений. С появлением компьютеров начали создаваться и широко внедрялись для изготовления чертежей, спецификаций, технологической документации разнообразные средства и системы автоматизированного проектирования (САПР);

системы автоматизированного управления производством (АСУП), назначенные для создания планов производства и отчетов о его ходе;

офисные системы, служащие для подготовки текстовых и табличных документов.

К концу XX века стало ясно, что эти достаточно дорогостоящие средства не оправдывают возлагающихся на них надежд: разумеется, некоторое повышение производительности труда происходит, однако не в тех масштабах, которые прогнозировались. Дело в том, что они не решают проблем информационного обмена между различными участниками жизненного цикла изделия (заказчиками, разработчиками, производителями, эксплуатационниками). При переносе данных из одной автоматизированной системы в другую требуются большие затраты труда и времени для повторной кодировки;

перекодировка заодно приводит к многочисленным ошибкам.

Оказалось, что разные системы «говорят на разных языках» и плохо понимают друг друга.

Более того, выяснилось, что бумажная документация и способы представления информации на ней ограничивают возможности использования современных ИТ. Так, трехмерная модель изделия, создаваемая в современной САПР, вообще не может быть адекватно представлена на бумаге.

С другой стороны, по мере усложнения изделий происходит резкий рост объемов технической документации. Сегодня они измеряются тысячами и десятками тысяч листов, а по некоторым изделиям (например, кораблям) — тоннами. При использовании бумажной документации трудно отыскать необходимые сведения, внести изменения в конструкцию и технологии изготовления изделий. Возникает множество ошибок, на устранение которых затрачивается время. В результате резко снижается эффективность процессов разработки, производства, эксплуатации, обслуживания, ремонта сложных наукоемких изделий.

Возникают трудности во взаимодействии заказчиков и производителей при подготовке и реализации контрактов, особенно при поставках сложной техники. Для преодоления этих трудностей потребовались новые концепции и новые идеи. Базовой стала идея информационной интеграции стадий жизненного цикла продукции (изделия), которая и легла в основу CALS. Она состоит в отказе от «бумажной среды», в которой осуществляется традиционный документооборот, и переходе к интегрированной информационной среде, охватывающей все стадии жизненного цикла изделия. Информационная интеграция заключается в том, что все автоматизированные системы, применяемые на различных стадиях жизненного цикла, оперируют не с традиционными документами и даже не с их электронными отображениями (например, отсканированными чертежами), а с формализованными информационными моделями, описывающими изделие, технологии его производства и использования. Эти модели существуют в интегрированной информационной среде как информационные объекты. Системы по мере необходимости могут извлекать их из интегрированной информационной среды, обрабатывать, создавать новые объекты и помещать результаты своей работы в ту же интегрированную информационную среду.

Чтобы все это было возможно, информационные модели и информационные объекты должны быть стандартизованы.

Интегрированная информационная среда представляет совокупность распределенных баз данных, в которой действуют единые стандартные правила хранения, обновления, поиска и передачи информации, через которую осуществляется безбумажное информационное взаимодействие между всеми участниками жизненного цикла изделия. Однажды созданная информация хранится в интегрированной информационной среде, не дублируется, не требует перекодировок в процессе обмена, сохраняет целостность.

Очевидно, что такой подход представляет своего рода революцию в организации взаимодействия всех участников жизненного цикла сложных наукоемких изделий.

Революционность подхода состоит в том, что многие поколения конструкторов, технологов, производственников воспитаны на основе совершенно другой культуры, базирующейся на сотнях стандартов ЕСКД, ЕСТД, СРПП, детально регламентирующих ведение дел с использованием бумажной документации. В условиях применения CALS эта культура должна претерпеть коренные изменения, поскольку:

- появляются принципиально новые средства инженерного труда;

- полностью изменяется организация и технология инженерных работ;

- должна быть существенно изменена, то есть дополнена и частично переработана, нормативная база;

тысячи специалистов должны быть переучены для работы с новыми средствами труда.

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

Кроме того, одна из важнейших задач стандартизации в рассматриваемой сфере — обеспечение информационной соВМестимости различных автоматизированных систем.

К настоящему времени СALS-технологии образуют самостоятельное направление в области ИТ. За рубежом создана нормативно-правовая база этого направления, которую составляют серии международных стандартов ISO, государственные стандарты и нормативные документы военного министерства США, НАТО, Великобритании и ряда других стран. Общее число этих стандартов — многие десятки и даже сотни, причем объемы документов подчас исчисляются тысячами страниц. На их разработку правительства и ведущие корпорации Запада израсходовали суммы, превышающие 1 млрд долл., и эта работа продолжается. Так, в ближайшем будущем конгресс США планирует выделить только на цели стандартизации СALS 47 млн долл.

Эволюция CALS CALS родилась в Департаменте обороны США в середине 80-х годов прошлого века.

Тогда эта аббревиатура расшифровывалась как «Компьютерная Поддержка Логистических Систем (Computer-Aidеd of Logistics Support)».

В то время компьютерные системы, закупленные военными ведомствами с целью усовершенствования процессов создания и технического обслуживания военной техники, не могли обмениваться информацией между собой и с аналогичными системами, использовавшимися в промышленности. Это приводило к изоляции вычислительных систем, ставших похожими на островки автоматизированной обработки данных. В 1985 году Департамент обороны США приступил к разработке CALS для решения вставших перед ним проблем. Вначале CALS была связана только с масштабными проектами американского военно-промышленного комплекса, позднее, в целях повышения производительности труда, принципы CALS стали применяться и в гражданской промышленности. Была произведена «демилитаризация» CALS, которая позволила американским организациям и предприятиям внедрять ее принципы. Благодаря быстрому росту интереса со стороны бизнесменов многих стран, стало происходить географическое расширение CALS. Трактовка аббревиатуры CALS несколько раз менялась.

В 1988 году в смысловом содержании CALS были сняты военные ограничения, и она стала называться «Компьютеризированные Поставки и Поддержка (Computer-Aided Acquisition and Support)». В этом варианте была усилена организационная направленность CALS. В 1993 году технология стала называться «Поддержка Непрерывных Поставок и Жизненного Цикла (Computer-Aided Acquisition and Lifecyclе Support)». В новом названии учитывалась методология параллельного проектирования, интегрированной логистической поддержки, управления конфигурацией и управления документопотоком. Это позволило интегрировать процессы на всем протяжении жизненного цикла изделий — от выражения потребности в изделии до его утилизации. Позднее, в 1995 году, под влиянием американского военно-промышленного комплекса CALS иногда стали называть «Бизнесом в Высоком Темпе (Commerce At Light Speed)», подчеркивая переориентацию этих технологий в направлении информационных магистралей и электронной коммерции.

Областями применения CALS принято считать:

- совершенствование деятельности в области разнородных процессов, происходящих на всех этапах жизненного цикла продукции;

- управление цепными поставками в течение всего жизненного цикла продукции (от создания концепции изделия до его утилизации);

- электронную интеграцию организаций, участвующих в этих процессах на различных этапах жизненного цикла продукции;

- управление поддержкой жизненного цикла продукции.

Философия проектирования как философия части жизненного цикла продукции родилась в 1987 году, когда Newport News получил от ВМФ заказ на разработку проекта подводной лодки «морской волк». Это было первое изделие, где появилась широкомасштабная возможность заставить работать идеи CALS и использовать усовершенствованный опыт и новую технологию для производства миллионов отдельных узлов лодки с соблюдением одинаково высоких требований как по качеству, так и по соВМестимости друг с другом.

К 1989 году, по мнению авторов CALS, вся техническая документация должна была представляться в электронном виде. К 1991 году вся конструкторско-технологическая документация должна была быть представлена в электронном виде. На первом этапе были определены «независимые стандарты», а также определен механизм обмена информацией с помощью магнитного носителя. На втором этапе в рамках всемирного консорциума ведущих технических организаций достигли соглашения об использовании нового стандарта описания данных, а также осуществлен доступ Министерства обороны США к базам данных его поставщиков. На самом деле лишь в 1995 году был заключен меморандум по общему пониманию и кооперации в использовании нового стандарта STEP (ISO 10303).

CALS-ориентированный подход внедряется заказчиками и поставщиками во многих отраслях промышленности: от автомобилестроения до предприятий ВПК;

от здравоохранения до производственной сферы. Каждое из предприятий адаптирует принципы CALS-технологий. Отрасли находятся на различных стадиях внедрения CALS: от полной деинтеграции информации до разработки и широкой реализации CALS-технологий.

Преимущества CALS Технологии, стандарты и программно-технические средства CALS обеспечивают эффективный и экономичный обмен электронными данными и безбумажными электронными документами, предоставляя возможности:

- параллельного выполнения сложных проектов несколькими рабочими группами (параллельный инжиниринг), что существенно сокращает время разработок;

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

- резкого сокращения количества ошибок и переделок, что приводит к уменьшению сроков реализации проектов и существенному повышению качества продукции;

- распространения средств и технологий информационной поддержки на послепродажные стадии жизненного цикла.

На экономические показатели предприятий, применяющих CALS-технологии, непосредственно влияют:

- сокращение затрат и трудоемкости процессов технической подготовки и освоения производства новых изделий;

- сокращение сроков вывода на рынок новых конкурентоспособных изделий;

- сокращение брака и затрат, связанных с внесением изменений в конструкцию;

- увеличение объемов продаж изделий, снабженных электронной технической документацией (в частности, эксплуатационной), составленной в соответствии с требованиями международных стандартов;

- сокращение затрат на эксплуатацию, обслуживание и ремонт изделий («затрат на владение»), которые для сложной наукоемкой продукции подчас не меньше затрат на закупку.

В публикациях можно отыскать некоторые количественные оценки эффективности внедрения CALS в промышленности США:

- прямое сокращение затрат на проектирование — от 10 до 30%;

- сокращение времени разработки изделий — от 40 до 60%;

- сокращение времени вывода новых изделий на рынок — от 25 до 75%;

- сокращение доли брака и объема конструктивных изменений — от 20 до 70%.

- сокращение затрат на подготовку технической документации — до 40%;

- сокращение затрат на разработку эксплуатационной документации — до 30%.

По зарубежным данным, потери, связанные с несовершенством информационного взаимодействия с поставщиками, только в автомобильной промышленности США составляют порядка 1 млрд долл. в год. Аналогичные потери имеют место и в других отраслях промышленности.

В тех же источниках указывается, что затраты на разработку реактивного двигателя GE 90 для самолета «Боинг-777» составили 2 млрд долл., а разработка новой модели автомобиля компании «Форд» стоит от 3 до 6 млрд долл. Это означает, что экономия от снижения прямых затрат на проектирование только по двум указанным объектам может составить от 500 млн до 2,2 млрд долл.

Как видим, внедрение CALS-технологий приводит к существенной экономии и получению дополнительной прибыли. Поэтому эти технологии и их отдельные компоненты широко применяются в промышленности развитых стран. Так, из числа 500 крупнейших мировых компаний, входящих в перечень «Fortune 500», почти 100% используют такой важнейший компонент CALS, как средства PDM (Product Data Management — «управление данными об изделии»). Среди предприятий с годовым оборотом свыше 50 млн долл. такие системы используют более 80%.

В связи с большими объемами ожидаемой экономии и дополнительных прибылей в эту сферу привлекаются значительные инвестиции, измеряемые миллиардами долларов. По данным зарубежных источников, инвестиции правительства США в сферу CALS-технологий составляют около 1 млрд долл. в год. Затраты других стран меньше, однако, например, правительство Финляндии затратило на национальную программу в этой области свыше млн долл., и примерно такую же сумму (около 25 млн долл.) вложили частные компании.

Корпорация General Motors в течение 1990—1995 годов израсходовала на эти цели 3 млрд долл. Средние затраты на один проект, посвященный решению локальной задачи в области CALS-технологий (например, разработка стандарта или программы), составляют 1,2—1, млн долл. при среднем сроке выполнения от двух до четырех лет.

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

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

- представление конструкторской и технологической документации в электронной форме;

- представление эксплуатационной и ремонтной документации в форме интерактивных электронных технических руководств, снабженных иллюстрированными электронными каталогами запасных частей и вспомогательных материалов, средствами дистанционного заказа запчастей и материалов;

- организация интегрированной логистической поддержки изделий на послепроизводственных стадиях их жизненного цикла;

- наличие и функционирование электронной системы каталогизации продукции;

- наличие на предприятиях систем менеджмента качества, соответствующих требованиям стандартов ИСО 9000:2000.

Выполнение этих требований предопределяет необходимость внедрения на отечественных предприятиях CALS-технологий в полном объеме.

В период с 1999 по 2002 год Минпромнауки РФ совместно с Госстандартом РФ и Минобразования РФ осуществили ряд мер, направленных на создание предпосылок к внедрению CALS-технологий в промышленности России.

1. Были созданы начальные элементы инфраструктуры, необходимой для разработки и внедрения CALS-технологий: Государственный научно-образовательный центр CALS-технологий, Научно-исследовательский центр (НИЦ) CALS-технологий «Прикладная логистика» и технический комитет ТК 431 Госстандарта России, координирующий разработку отечественной нормативной базы.

2. Подготовлены научно-методические разработки: концепция развития CALS технологий в промышленности России, концепция интегрированной логистической поддержки наукоемких изделий и концепция внедрения CALS-технологий на машиностроительном предприятии.

3. Созданы программные средства, реализующие CALS-технологии. В их числе — программный продукт Technical Guide Builder, предназначенный для автоматизированной подготовки электронной технической эксплуатационной документации на экспортируемую продукцию, соответствующей требованиям CALS-стандартов. Создание с помощью этого продукта интерактивных электронных технических руководств значительно повышает конкурентоспособность продукции. Другой продукт — PDM STEP Suite — служит для управления данными об изделии в процессе конструирования и технологической подготовки производства, что необходимо предприятиям, разрабатывающим наукоемкую продукцию и продающим лицензии на ее производство.

4. Разработаны методические основы создания интегрированной системы управления качеством продукции, соответствующей требованиям стандартов ИСО серии 9000 версии 2000 года.

Работы по внедрению CALS-технологий в промышленность России продолжаются, но требуют адекватной финансовой поддержки государства, контроля и содействия в реализации усилий предприятий со стороны Минпромнауки РФ, Госстандарта РФ и других министерств и ведомств России.

Успешное решение проблем освоения CALS непосредственно связано с такими задачами, как обеспечение национальной безопасности и конкурентных позиций России на мировых рынках.

Лекция 9 Стандартизация требований к современным интерфейсам пользователей План 1. Требования ГОСТ к разработке приложений пользователя 2. Требования стандартов к формированию пользовательского интерфейса на примере Windows Forms 3. Структура и классификация пользовательского интерфейса Литература: 1, 9, 12, 14.

При разработке, тестировании и При разработке, тестировании и оценке качества пользовательского интерфейса необходимо применять соответствующие государственные и отраслевые стандарты. Однако это сразу порождает целый ряд вопросов, например: как стандарты соотносятся с различными аспектами пользовательского интерфейса? Что такое правильный интерфейс? Как применять эргономические стандарты при проектировании и тестировании интерфейса? Влияет ли стандартизация на качество разрабатываемых изделий?

оценке качества пользовательского При разработке, оценке и тестировании приложений пользователей следует применять государственные стандарты.

При разработке, тестировании и оценке качества пользовательского интерфейса необходимо применять соответствующие государственные и отраслевые стандарты.

Разработка программного обеспечения на разных его фазах всегда сопряжена с принятием серьезных управленческих и инженерных решений. Эффективность выбора таких решений можно повысить за счет использования формальных методов - объективный анализ фактов, обоснование сделанных выводов и оценка последствий различных действий позволяют свести к минимуму риски, связанные с разработкой программного продукта Процесс управления требованиями традиционно считается одним из ключевых при создании автоматизированных систем. Наибольшие риски проектов связаны с высокой изменчивостью требований и ошибками в их определении. Методика, основанная на международных и отечественных стандартах в области управления жизненным циклом автоматизированных систем, направлена на снижение таких рисков. Проблемы при выполнении проектов создания автоматизированных систем могут возникать из-за неформального сбора информации, предполагаемой функциональности, ошибочных или несогласованных нефункциональных требований к системе, а также нерегламентированной процедуры их изменения Приведем перечень основных стандартов в области автоматизации различных сфер деятельности. Некоторые из низ будем использовать в лабораторном практикуме.

ГОСТ 34.201-89 Виды, комплектность и обозначения документов при создании автоматизированных систем ГОСТ 34.320-96 Концепции и терминология для концептуальной схемы и информационной базы ГОСТ 34.321-96 Информационные технологии. Система стандартов по базам данных.

Эталонная модель управ ГОСТ 34.601-90 Автоматизированные системы. Стадии создания.

ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы (Взамен ГОСТ 24.201-85) ГОСТ 34.603-92 Информационная технология. Виды испытаний автоматизированных систем РД 50-34.698-90 Автоматизированные системы. Требования к содержанию документов.

ГОСТ Р ИСО/МЭК 8824-3-2002 Информационная технология. Абстрактная синтаксическая нотация версии один ГОСТ Р ИСО/МЭК 10746-3-2001 Управление данными и открытая распределенная обработка.

ГОСТ Р ИСО/МЭК 15271-02 Процессы жизненного цикла программных средств ГОСТ Р ИСО/МЭК 15910-2002 Процесс создания документации пользователя программного средства Windows Forms представляет собой одну из двух технологий, используемую в Visual C# для создания интеллектуальных клиентских приложения на основе Windows, выполняемых в среде.NET Framework. Технология Windows Forms специально создана для быстрой разработки приложений, в которых обширный графический пользовательский интерфейс не является приоритетом. Для создания пользовательского интерфейса используется конструктор Windows Forms, и пользователь получает доступ к другим возможностям времени разработки и времени выполнения. Быстрота и удобство создания пользовательских интерфейсов в Visual C# обеспечивается благодаря Windows Form Designer или Windows Presentation Foundation (WPF) Designer. Создание пользовательских интерфейсов происходит в три основных этапа.

1. Добавление элементов управления на поверхность разработки.

2. Установка начальных свойств для элементов управления.

3. Написание обработчиков для заданных событий.

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

Пример контрольного списка. Использование контрольных списков является эффективным и экономичным средством повышения уровня качества программных продуктов. Их использование, применительно к интерфейсу, не требует выполнения дорогостоящих процедур юзабилити-тестирования, достаточно большое количество контрольных списков по интерфейсу можно найти в интернете в свободном доступе. Естественно, что в каждом конкретном случае необходимо разрабатывать свой собственный контрольный список, поскольку он должен учитывать специфику разрабатываемого программного средства и возможности средств разработки. Поэтому настоящий контрольный список является скорее шаблоном, в котором представлены основные разделы. При разработке, тестировании и оценке качества пользовательского интерфейса необходимо применять соответствующие государственные и отраслевые стандарты. Однако это сразу порождает целый ряд вопросов, например: как стандарты соотносятся с различными аспектами пользовательского интерфейса? Что такое правильный интерфейс? Как применять эргономические стандарты при проектировании и тестировании интерфейса? Влияет ли стандартизация на качество разрабатываемых изделий?

Структура и классификация пользовательских интерфейсов В дизайне пользовательского интерфейса можно условно выделить декоративную и активную составляющие. К первой относятся элементы, отвечающие за эстетическую привлекательность программного изделия. Активные элементы подразделяются на операционные и информационные образы моделей вычислений и управляющие средства пользовательского интерфейса [2], посредством которых пользователь управляет программой. Управляющие средства различных классов программных изделий могут значительно различаться. Поэтому необходимо провести хотя бы предварительную классификацию интерфейсов и соответствующих им управляющих средств.

На первом уровне такой классификации полезно выделить классы интерфейсов, происхождение которых связано с используемыми базовыми техническими средствами человеко-машинного взаимодействия. Исторически, появление таких средств вызывает возникновение новых классов пользовательского интерфейса. Впрочем, с появлением новых средств использование интерфейсов старых классов не обязательно полностью прекращается. Классы интерфейса являются слишком широкими понятиями. Классы, задаваемые базовыми интерактивными средствами, целесообразно разбить на подклассы, например, в пределах графического класса различаются подклассы: двухмерные и трехмерные интерфейсы. По этой классификации широко распространенный интерфейс WIMP относится к первому из указанных подклассов. Сегодня развиваются такие новые классы интерфейсов, как SILK (речевой), биометрический (мимический) и семантический (общественный) [3]. В основе управляющих средств пользовательского интерфейса лежит тот или иной интерфейсный язык. При этом роль синтаксиса играют используемые графические образы и их динамические свойства. О типах управляющих средств пользовательского интерфейса мы будем говорить, имея в виду различные формы (элементы дизайна) типизированных управляющих элементов пользовательского интерфейса определенного подкласса. Дизайн конкретных реализаций интерфейса может включать композицию, вообще говоря, различных типов управляющих средств, информационные образы предметной области и декоративные элементы (в первую очередь метафоры интерфейса). Компоненты дизайна не произвольны, а образуют некоторое стилевое единство. Система управляющих средств пользовательского интерфейса конкретного подкласса является одновременно шаблоном возможного «текста» на некотором (неявном) языке пиктограмм управления и имитацией с помощью средств машинной графики управляющей панели инструмента обработки данных. В разных типах интерфейса удельная роль языковой и имитационной составляющей может быть различной. Показатель синтаксической правильности пользовательского интерфейса вводится в предположении существование некоторого эталона «правильного» интерфейса, в качестве которого естественно считать нормативные документы (стандарты), содержащие явное или неявное описание синтаксиса на уровне пиктограмм и способов манипуляции ими.

Знаковая система графического пользовательского интерфейса определяется конечным словарем графических управляющих элементов (ГУЭ). Каждый ГУЭ обладает стандартизированными свойствами описанного вида, составляющими его регламент.

Нарушение регламента ГУЭ следует рассматривать как ошибку проектирования пользовательского интерфейса. Правильность управляющих средств пользовательского интерфейса конкретного приложения — это соответствие управляющих средств синтаксису интерфейсов соответствующего типа. Для экспертной оценки правильности управляющих средств пользовательского интерфейса на основе таких стандартов удается сформировать списки оценочных элементов (в терминах ГОСТ 28195-89 «Оценка качества программных продуктов. Общие положения»). В англоязычной литературе говорят о контрольных списках (cheklists). Обратим внимание на отличие элементов контрольных списков от тестов (test cases), используемых при обычном тестировании. Обычные тесты являются конкретными частными значениями входных данных, в то время как элементы контрольных списков — это обобщенные правила оформления и функционирования управляющих средств пользовательского интерфейса. Тестирование правильности пользовательского интерфейса возможно, если в формулировке требований к пользовательскому интерфейсу в техническом задании на программный продукт указывается тип (стиль) выбранного интерфейса, что, кстати, требует ГОСТ Р ИСО/МЭК 12119-2000 (п. 3.1.5).

Качество интерфейса — эргономический аспект. Качество определяется в ГОСТ Р ИСО/МЭК 9126-93 как «объем признаков и характеристик продукции или услуги, который относится к их способности удовлетворять установленным или предполагаемым потребностям». При комплексной оценке показателей качества программного продукта качество пользовательского интерфейса вносит определяющий вклад в такую субхарактеристику качества, как практичность (usability) (ГОСТ Р ИСО/МЭК 9126-93. С семиотической точки зрения качество соотносится со стандартизированностью как семантика и прагматика с синтактикой. Другими словами, качество характеризует содержание (смысл) и полезность текста, в то время как стандартизированность — грамотность (корректность). В качестве пользовательского интерфейса можно выделить два аспекта интерфейса — функциональный и эргономический. О качестве функциональности интерфейса трудно говорить безотносительно предметной области, например, сформулировать «руководящие принципы функциональности» пользовательского интерфейса. Формально его можно связать со степенью «соответствия задаче» (ISO 9241-10 1996, p.10).

Нормативные требования по эргономике пользовательского интерфейса отличаются по своей природе от синтаксических и манипуляционных правил — они относятся к психофизиологическим свойствам конкретной реализации уже выбранного типа (стиля) пользовательского интерфейса (и соответствующего стандарта) в конкретном приложении. В этих условиях эргономические стандарты могут лишь требовать достижения некоторых общих руководящих эргономических принципов [9], которым должно удовлетворять реализация в приложении выбранного тип (стиля). При этом предполагается, что приложение должно оптимально инкорпорировано в техническую среду. При разработке, тестировании и оценке качества пользовательского интерфейса необходимо применять соответствующие государственные и отраслевые стандарты.

В первом подходе оценку производит конечный пользователь (или тестер), суммируя результаты работы с программой в рамках следующих показателей ISO 9241-10- Ergonomic requirements for office work with visual display terminals (VDTs). P. 11. Guidance on usability specification and measures:

• эффективности (effectiveness) - влияния интерфейса на полноту и точность достижения пользователем целевых результатов;

• продуктивности (efficiency) или влияния интерфейса на производительность пользователя;

• степени (субъективной) удовлетворенности (satisfaction) конечного пользователя этим интерфейсом.

Эффективность является критерием функциональности интерфейса, а степень удовлетворенности и, косвенно, продуктивность — критерием эргономичности. Вводимые здесь меры соответствуют общей прагматической концепции оценки качества по соотношению «цели/затраты».

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

Стандарты и качество. Формально стандартизированность пользовательского интерфейса уместно связать с другими инфраструктурными субхарактеристиками качества программного продукта, такими, как соответствие (conformance) (в том числе и соответствие стандартам) и взаимозаменяемость (replaceability) (ГОСТ Р ИСО МЭК 9126-93). Выбор конкретного средства проектирования (языки быстрой разработки приложений, CASE средства, конструкторы графических интерфейсов) может привести разработчика к необходимости придерживаться стандарта интерфейса, положенного в его основу.С другой стороны, выбор разработчиком стандарта типа (стиля) пользовательского интерфейса, адекватного предметной области и используемой ОС, потенциально должен обеспечить, хотя бы отчасти, выполнение таких принципов качества пользовательского интерфейса, как естественность и согласованность в пределах рабочей среды [13]. Все кнопки, запускающие действия, имеют текст в инфинитивной форме глагола (пример: искать), а не другую часть речи либо форму глагола (пример: готово). Давать кнопке текст «ОК» можно, только если какой-либо глагол не вмещается. Кликабельный размер кнопок совпадает с их видимым или логическим размером. Между кнопками, стоящими рядом, должно быть пустое пространство, щелчок по которому не отрабатывается. Нет разных состояний кнопок, которые выглядят одинаково. Недоступные команды не исчезают с экрана, а становятся заблокированными. Частотные кнопки снабжены не только текстом, но и пиктограммами;

редко используемые кнопки - только текстовыми подписями. В модальных диалоговых окнах нет кнопок «Применить».

Поля ввода. В полях ввода уже стоят наиболее вероятные значения. Если в поле вводится численное значение, границы диапазона выводятся во всплывающей подсказке.

Если в поле вводится численное значение из ограниченного диапазона, поле снабжено крутилкой (Spinner). Длина полей не меньше, и, по возможности, не больше, длины вводимых в них данных. Если поле предназначено для ввода заметного количества текста, оно многострочное. Многострочные поля имеют максимально возможную высоту;

нет резервов для их увеличения.

Списки. В списках уже стоят наиболее вероятные значения. Если список содержит более 50 элементов, используется фильтр или режим поиска. Нет часто используемых коротких списков (менее пяти элементов);

такие списки представлены как группы радиокнопок или чекбоксов. Ширина списков не меньше ширины входящих в них элементов.

Элементы списка отсортированы;

либо структурно, т.е. по общим признакам, либо по алфавиту, либо по частотности (только списки меньше 7 элементов). Если в списке более отсортированных по алфавиту элементов, первыми тремя элементами являются наиболее частотные элементы. Они также повторяются на своих алфавитных местах. Многострочные списки множественного выбора снабжены чекбоксами возле каждого элемента (списки старого стиля отсутствуют). Многострочные списки имеют высоту не менее 4 строк. Если есть свободное место, используются расширенные комбобоксы, а не однострочные.

Чекбоксы и радиокнопки. Если чекбоксов в группе больше 10, вводится дополнительный, выставляющий/снимающий все чекбоксы. Внутри группы радиокнопок одна обязательно установлена по умолчанию. Чекбоксы и радиокнопки внутри своих групп расставлены по вертикали. Если в окне, помимо терминационных кнопок, есть только набор радиокнопок, двойной щелчок по радиокнопке устанавливает ее и закрывает окно.

Взаимодействие. Система, завершив длительную операцию (больше минуты работы), пищит через встроенный динамик компьютера. Если в интерфейсе не используется непосредственного манипулирования, система не имеет своих курсоров. Если непосредственное манипулирование применяется, свои курсоры применяются, только если аналогов из ОС не существует.

Системные сообщения и отработка ошибок. В формах ввода проверка корректности вводимых значений выполняется прямо во время ввода;

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

Если окно с текстом о некорректности введенных данных всплывающее — оно не должно заслонять собой поле ввода, где содержится текст с ошибкой. Текст сообщений о проблемах состоит из трех частей: в первой кратко описывается проблема, во второй части - как ее решить, в третьей - описывается, как не допускать возникновения этой проблемы в дальнейшем. Статусные сообщения («Синхронизация успешно завершена») выводятся только в строке статуса.

Клавиатура. В формах ввода нажатие табуляции ведет к правильной последовательности перемещения по форме. Обработка формы запускается не только по нажатию на терминационую кнопку, но и по нажатию клавиши Enter на последнем поле этой формы. Для наиболее частотных элементов управления (включая меню) установлены клавиши быстрого вызова. Каждому пункту меню назначены ALT-комбинации (выделены подчеркиванием). ALT-комбинации и горячие клавиши стандартные. Если горячих клавиш больше 40, в интерфейсе есть способ их изменить. По нажатию клавиши Tab переход от элемента к элементу внутри формы осуществляется сверху вниз слева направо.

Индикация. Индикация цветом не является единственной;

если она используется, система снабжена и другой индикацией.

Пиктограммы. В группах пиктограмм нет пиктограмм, по цвету и форме сходных между собой. Нет пиктограмм со стандартными значениями, но нестандартными сюжетами.

В пиктограммах нет текста. В наборах пиктограмм пиктограммы одного значения, но разных размеров используют одни и те же особенности и/или сюжет.

Окна. На растягивающихся окнах есть индикатор растягиваемости. Заголовки окон соответствуют названиям элементов, при помощи которых окна были вызваны. Если окно вызывается элементом, не имеющим явного названия, в заголовке окна отражается название экранной формы. Тип окна (модальное, немодальное, возможность минимизации/максимизации) был выбран осознанно, в соответствии с задачами пользователей. В диалоговых окнах отсутствуют меню или инструментальные панели.

Кнопки Применить используются только в окнах-палитрах (вместо кнопок ОК).

Строка статуса. В строке статуса выводится только информация о текущем состоянии системы и кнопки (не выглядящие кнопками) для функций, предназначенных только опытным пользователям. Индикаторы выполнения выводятся в строке статуса.

Исключение: окна-маcтера, в них индикаторы выполнения можно выводить внутри самих окон.

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

Элементы, открывающие вложенные меню, выглядят иначе, чем терминальные элементы.

Контекстные меню. На всех объектах, видимых в интерфейсе, есть специфичное для каждого объекта контекстное меню. В контекстных меню не более 10 элементов. В контекстных меню элементы отсортированы по убыванию частоты их использования. Все элементы контекстных меню присутствуют и в других фрагментах интерфейса;

нет команд, вызываемых только из контекстных меню.

Структура интерфейсных форм. В группах интерактивных элементов (поля форм, элементы меню и т. п.) этих элементов не больше семи. Кнопка «Отмена» всегда самая правая. Многостраничные формы имеют указание на то, что они многостраничные;

пользователь всегда видит количество оставшихся экранов (пример: «Экран x из y»). Если в форме есть несколько кнопок, одна является кнопкой по умолчанию. Если кнопка в форме только одна, она не может быть кнопкой по умолчанию. Опасные для пользователя кнопки не являются кнопками по умолчанию. Если в окне есть свободное место, наиболее частотная терминационная кнопка больше остальных. Кнопки находятся в секции, на которую они оказывают непосредственное воздействие. Терминационные кнопки (управляющие окном) расположены либо снизу в ряд, либо справа в колонку. Кнопки, относящиеся ко всему блоку вкладок, расположены за пределами блока. Если окно или вкладка имеет автоматически пополняемое содержимое, например, в нем перечислены приходящие сообщения, в названии элемента интерфейса, который открывает окно или вкладку, выводится число объектов в этом окне и отдельно число новых объектов. Пример: Документы (8/3). Пункты меню и кнопки, инициирующие другие действия пользователя, обозначены в конце многоточием (…). Примеры: элемент «Сохранить как…» требует многоточия, т.к. пользователь должен выбрать название файла, а элемент «О программе» многоточия не требует, т.к. на открывающемся окне нет самостоятельных интерфейсных элементов. Подписи к интерфейсным элементам размещены единообразно. Недоступные в данный момент интерфейсные элементы заблокированы, а не скрыты. В интерфейсе присутствуют сообщения о выполнении того или иного действия. Например, сообщение о том, что данные успешно сохранены или что-то удалено и т. д.

Формы ввода. У формы ввода есть название. Во всех формах, служащих для сбора информации, есть пункты «Другое» и «Не применимо» или подобный. Все поля, обязательные для заполнения, помечены, и есть соответствующее пояснение. Поле «Отчество» никогда не является обязательным для заполнения. Многостраничные формы ввода имеют кнопки «Назад» и «Далее». Во всех формах, служащих для сбора информации, есть описание целей сбора данных, объясняется, что с этими данными будет сделано и что не будет.

Текст. На все главные интерфейсные элементы повешены всплывающие подсказки, текст которых отражает результат использования этих элементов. В интерфейсе отсутствуют жаргонизмы. В интерфейсе отсутствуют отрицательные формулировки (например, чекбокс «Не показывать примечания» неприемлем, взамен него нужно выводить чекбокс «Показывать примечания»). Ни один элемент не называется по-разному в разных местах (интерфейсный глоссарий не просто сделан в явной форме, но и выверен). В тексте всех подтверждений дается наименование объекта, над которым совершается подтверждаемое действие. Для улучшения удобочитаемости длинные числа разбиваются неразрывным пробелом по три цифры: 1 234 567. Каждый элемент списка содержит на конце точку или начинается с прописной буквы по следующему правилу: «Текст всех элементов начинается со строчной буквы. Все элементы оканчиваются по последней букве слова без каких-либо знаков препинания, кроме последнего, который оканчивается точкой. Исключение: если хоть один элемент списка содержит более одного предложения, все элементы начинаются с заглавной буквы и заканчиваются точкой». Любому списку предшествует, по меньшей мере, один абзац текста. В таблицах все столбцы с цифрами выравниваются по правому краю.


Точка в конце фразы отсутствует в заголовке (если он отделен от текста), в конце подписи под рисунком и в таблице. Подписи к интерфейсным элементам начинаются с прописной буквы и заканчиваются двоеточием.

Вопросы для контроля знаний 16. Каковы основные проблемы развития информатики и информатизации общества 17. Перечислить законы информатики 18. Какой из законов, на ваш взгляд, является наиболее актуальным в настоящее время 19. Какие аспекты раскрывает понятие массовости информации и в чем их смысл.

20. Как измерить ценность информации 21. Классифицируйте основные признаки информации.

22. Что понимается под субстанцией, и как проявляется субстациональная несамостоятельность информации.

23. В чем смысл преемственности информации.

24. Охарактеризуйте прагматический аспект изучения информации 25. Охарактеризуйте технический аспект изучения информации 26. Охарактеризуйте семантический аспект изучения информации 27. Охарактеризуйте лингвистический аспект изучения информации 28. Раскройте смысл пятой информационной революции.

29. Сформулируйте основную задачу информатики.

30. Кратко раскрыть аспект становления информатики как науки.

Перечень лабораторных Тема Оборудов. Литература Объем работ Научный подход к Лабораторная работа № 1. ПК 1, 2, 18, 21, 22, 27, изучению Семантический, 28, прикладной лингвистический, информатики в прагматический подходы к экономике измерению информации Цели и задачи Лабораторная работа № 2. ПК 1, 2, 18, 21, 22, 27, прикладной Проектирование приложения 28, информатики в и интерфейса пользователя в информационном соответствии нормативными обществе требованиями ГОСТ Лабораторная работа № 3. ПК 1, 2, 18, 21, 22, 27, Современные технологии 28, программирования Лабораторные работы № 4 ПК 1, 2, 18, 21, 22, 27, Общие принципы, методы и 28, средства проектирования архитектуры и структуры программного обеспечения Лабораторные работы №5 ПК 1, 2, 18, 21, 22, 27, Современные подходы к 28, обработке потоков Соременные подходы информации к производству и Лабораторные работы № 6 ПК 1, 2, 18, 21, 22, 27, обработке Технология виртуального и 28, информации объектно-ориентированного программирования Лабораторная работа № 7 ПК Изучение подходов к решению проблемы визуального моделирования информационных потоков Лабораторные работы № 8 ПК 1, 2, 18, 21, 22, 27, Изучение подходов к 28, решению проблемы качества обработки информации 3. Лабораторные работы Методические указания по выполнению лабораторных работ (с описанием задания и порядка выполнения лабораторных работ) Лабораторная работа № 1. Научный подход к изучению прикладной информатики в экономике Цель: Сформировать представление о существующих нормативных документах, формирующих требование к составу и функциям разрабатываемых информационных продуктов.

Задачи:

1.Изучение особенностей ГОСт серии 19, 34.

2. Изучение особенностей разработки Технического задания (ТЗ) на проектируемый информационный продукт.

3. Создание ТЗ в соответствии с ГОСТ серии 34.602-89.

Задание:

1. Изучить примеры разработанных ТЗ 2. Разработать ТЗ (первые 3 пункта) Самостоятельная работа 1. Оценить соответствие ТЗ требованиям заказчика 2. Сформировать документ «Требования к программному продукту»

Ответить на вопросы 1. Какие функциональные требования предъявляются к информационному продукту заказчиком?

2. Какие системные требования предъявляются к информационному продукту заказчиком?

3. Какие требования ГОСТ предъявляются к разработке ТЗ на информационный продукт 4. Как создать информационный проект?

5. Основные компоненты проекта?

6. Структурные части программного модуля?

7. Описать процесс создания проекта, начиная с ТЗ 8. Структурные части проекта?

9. Описать структуру меню.

Лабораторная работа № 2. Цели и задачи прикладной информатики в информационном обществе Цель. Проектирование приложения и интерфейса пользователя в соответствии нормативными требованиями ГОСТ Задачи:

- Изучение особенностей среды программирования Visual Studio.Net.

- Изучение особенностей современной технологии программирования на языке C#.

- Создание Windows-приложений.

- разработка ТЗ на проект АИС в соответствие с требованиями ГОСТ 34.602- Задание:

1. Изучить примеры разработанных ТЗ 2. Разработать ТЗ (пп.4-9) Самостоятельная работа 1. Представить описание документа «Требования заказчика к информационному продукту (информационному проекту).

2. Доработать ТЗ на информационный проект.

3. Оценить соответствие ТЗ требованиям заказчика 4. Представить проект меню 5. Сформировать документ «Инструкция пользователю»

Ответить на вопросы 1. Какие функциональные требования предъявляются к информационному продукту заказчиком?

2. Какие системные требования предъявляются к информационному продукту заказчиком?

3. Какие требования ГОСТ предъявляются к разработке ТЗ на информационный продукт 4. Как создать информационный проект?

5. Основные компоненты проекта?

6. Структурные части программного модуля?

7. Описать процесс создания проекта, начиная с ТЗ 8. Структурные части проекта?

9. Описать структуру меню.

10. Описать функциональное назначение каждого блока меню.

Лабораторная работа №3. Современные подходы к производству и обработке информации Цель: Получить основные навыки работы в современной среде программирования Visual Studio.Net.

Задачи:

1. Изучение особенностей среды программирования.

2. Изучение особенностей современной технологии программирования на языке C#.

3. Создание Windows-приложений.

4. Обработка событий мыши.

5. Вывод текстовой информации в окно пользовательского интерфейса.

Формируемые компетенции:

- навыки разработки прикладных алгоритмов в современной среде визуального программирования Visual Studio.NET;

- навыки проектирования архитектуры и структуры прикладных алгоритмов с использованием современных CASE – технологий;

- навыки логической организации программы на языке C#.

Задание:

1. Ознакомиться со средой проектирования Visual Studio.NET 2. Создать простейшее приложение средствами Studio.NET.

3. Изменить размеры окна приложения, цвет фона и заголовок.

4. Реализовать обработку щелчка левой и правой кнопки мыши. По левой кнопке – выводить координаты курсора мыши в точке его нахождения.

5. Реализовать вывод текстовой информации в окно формы приложения пользователя. По правой – отображать диалоговое окно с сообщением «Нажата правая кнопка мыши» и очищать окно приложения от надписей.

Теория:

В состав среды проектирования Microsoft Visual Studio.NET встроены средства, облегчающие программисту разработку приложений. Данная среда позволяет быстро создавать шаблоны новых приложений. Генерируемый средой Visual Studio.NET каркас стандартного приложения Windows содержит ряд классов. Класс формы (Form1) предназначен для создания интерфейса и программирования функциональности приложения.

Соответственно, прежде всего, с ним работает разработчик приложения Windows.

C формой можно работать в режиме дизайна и в режиме кодирования. В режиме дизайна доступна панель настраиваемых свойств формы (Properties), которая активизируется через команду меню, вызываемого по щелчку правой кнопкой мыши в области формы.

Используя свойства, доступные в панели свойств, можно определить положение, размер, цвет и особенности управления для создаваемого окна. Свойство Text позволяет изменить заголовок окна. Свойства Size и DesktopLocation задают размер и положение окна при его отображении. Свойство ForeColor служит для указания цвета переднего плана по умолчанию для всех элементов управления, размещенных в форме. Свойства BorderStyle, MinimizeBox и MaximizeBox определяют, можно ли будет свернуть, развернуть или изменить размер формы во время исполнения программы.

Для каждого свойства, изменяемого в панели свойств, создается соответствующий код. Он помещается в файл Form1.Designer.cs, в секцию, отмеченную как Windows Form Designer generated code. Можно раскрыть ее и просмотреть сгенерированный код.

Программы Windows, основанные на графическом интерфейсе пользователя, управляются событиями. С# выполняет функции обработки сообщений с помощью специальных функций - делегатов. Помимо методов и свойств формы содержат коллекции обработчиков событий. Если требуется обрабатывать событие, то вы должны выбрать в панели свойств формы закладку «Events» и двойным щелчком по пустой ячейке, расположенной справа от имени интересующего события, сгенерировать шаблон функции обработчика события.

Некоторые события формы и элементов управления:

Click - Возникает при щелчке мыши DoubleClick - Возникает при двойном щелчке мыши KeyDown - Возникает при нажатии клавиши KeyUp - Возникает при отпускании клавиши MouseDown - Происходит, когда нажимается кнопка мыши, а указатель мыши находится над объектом MouseEnter - Возникает, когда указатель мыши попадает в область объекта MouseLeave - Возникает, когда указатель мыши покидает область объекта MouseMove - Возникает при перемещении мыши над объектом MouseUp - Возникает при отпускании кнопки мыши в области объекта Resize - Возникает при изменении размера объекта Обработчик события получает два аргумента – ссылку на объект, к которому относится событие, и дополнительную информацию о событии (тип EventArgs или производный от него).


Обработчики событий от мыши получают в качестве второго аргумента объект типа MouseEventArgs.

Свойства, определенные в классе MouseEventArgs:

Button Позволяет получить информацию о том, какая кнопка мыши нажата (в виде значений перечисления MouseButtons) Clicks Позволяет получить информацию о том, сколько раз нажата и отпущена кнопка мыши Delta Позволяет получить информацию (в виде положительного или отрицательного числового значения) о повороте колесика мыши X Позволяет получить координату X для указателя мыши во время щелчка Y То же самое для координаты Y Операции рисования и вывода текста инкапсулирует класс System.Drawing.Graphics. В нём присутствуют методы для отображения линий, кривых, строк и других графических элементов.

Для выполнения вывода на экран в методах класса формы требуется предварительно получить объект Graphics. Это обеспечивается добавлением в метод следующей строки:

Graphics g = CreateGraphics();

Текстовые строки в C# хранятся в объектах типа string.

Для вывода текста в окно необходимо объявить переменную этого типа, проинициализировать её и передать методу DrawString класса Graphics.

Например:

string s = "Hello, World!";

g.DrawString(s, new Font("Times New Roman", 8), new SolidBrush(Color.Black), new Point(100, 200);

В операции вывода строки дополнительно указываются три объекта типов Font, SolidBrush и Point, задающие соответственно шрифт, используемый для вывода, цвет шрифта и координаты точки привязки выводимого текста. Со строками типа string можно выполнять операцию сложения, задаваемую знаком "+ ". Числовые типы языка C# можно переводить в строковое представление вызовом для них функции toString. Например: string s = e.toString();

Структура программы. В этом разделе обсудим общую структуру программ на C# - как организовать код, какие элементы служат для этого.

Логическая организация программы Логическая организация кода помогает лучше в нем ориентироваться, делает код более понятным и облегчает его повторное использование. C# отражает иерархию пространств имен, принятую в.NET. Все классы могут быть распределены по пространствам имен, которые образуют иерархическую структуру. Например, пространство имен System включает в себя пространства имен Collections, Data и другие, а Data включает в себя SqlClient, OleDbClient, SqlTypes. Полные имена последних - System.Data.SqlClient, System.Data.OleDbClient, System.Data.SqlTypes. Видно, что в полных именах пропечатывается весь "путь" к namespace от корня, при этом уровни разделяются точкой.

Удобно все классы проекта разделить в иерархическую структуру, более того, все проекты, которые вы выполняются, могут иметь общую иерархию, начинающуюся с имени вашей компании. Например, в компании с именем HT Electronics, которая выполняет работу над проектами с именами Web Admin и Processor Manager, классы, относящиеся к этим проектам могут быть расположены в пространствах имен com.HTElectronics.WebAdmin и com.HTElectronics.ProcessorManager. Также может быть общая библиотека классов в пространстве имен com.HTElectronics.Common.

Последнее, о чем следует напомнить здесь - это о методе Main - точке входа в программу (нужно решить, где будет начинаться выполнение программы).

Физическая организация программы. Под физической организацией кода мы понимаем его размещение по файлам и каталогам. В Java существуют достаточно жесткие ограничения соответствие имен файлов именам классов, имен каталогов именам пакетов, размещение не более одного public-класса в файле и т.д. В C# подобных ограничений нет. Так что организация файлов и каталогов лежит на программисте. В общем случае невозможно отразить структуру пространств имен структурой каталогов - в одном файле могут быть объявлены классы из разных пространств. Причем отсутствие такого ограничения не уменьшает логичности структуры, зато часто это удобно - например, в Web-приложениях.

Выполнение задания:

Для выполнения пункта 2 задания создайте проект типа Windows Application, выбрав пункт меню File | New Project | Windows Forms Application.

В поле Name окна «New Project» укажите название создаваемого проекта (например, wf1).

Нажмите кнопку “OK”. Окно Visual Studio примет вид, как показано на рис. 1.

Форма проекта Структура проекта Окно свойств Рис. 1. Окно проекта в Visual Studio Для выполнения пункта 3 следует в панели свойств формы (Properties) задать значения свойств BackColor, Size, Text. Следует присвоить этим полям значения, задающие соответственно белый цвет, размер 600x450 и имя, которое вы считаете подходящим для разрабатываемого вами графического редактора.

Для выполнения пункта 4 задания необходимо добавить к классу Form1 обработчик события MouseDown (на панели событий, вызываемой кнопкой в окне свойств). Для различения нажатий на левую и правую кнопки мыши следует проверять значение поля Button аргумента MouseEventArgs. Если оно равно MouseButtons.Left, то была нажата левая кнопка, если MouseButtons.Right – правая. Пример выражения проверки: if (e.Button == MouseButtons.Left) Диалоговое окно с сообщением создаётся с помощью функции MessageBox.Show(), которой передаётся два аргумента - строка выводимого в окне текста и строка заголовка окна. Для очистки окна следует вызвать через объект типа Graphics функцию Clear(), передав ей в качестве аргумента значение цвета Color.White.

В итоге должен получиться следующий текст программы:

using System;

using System.Collections.Generic;

using System.ComponentModel;

using System.Data;

using System.Drawing;

using System.Linq;

using System.Text;

using System.Windows.Forms;

namespace wf { public partial class Form1 : Form { public Form1() { InitializeComponent();

} bool doDraw = false;

int start_downX;

int start_downY;

int end_downX;

int end_downY;

private void Form1_MouseDown(object sender, MouseEventArgs e) { Graphics g = Graphics.FromHwnd(this.Handle);

if (e.Button == MouseButtons.Left) { start_downX = e.X;

start_downY = e.Y;

doDraw = true;

} if (e.Button == MouseButtons.Right) { g.Clear(Color.White);

MessageBox.Show("Нажата правая кнопка мыши");

} } private void Form1_MouseMove(object sender, MouseEventArgs e) { if (doDraw) { Graphics g = Graphics.FromHwnd(this.Handle);

Pen pen = new Pen(Color.Black);

pen.DashStyle = System.Drawing.Drawing2D.DashStyle.Dash;

Rectangle r = Rectangle.FromLTRB(start_downX, start_downY, e.X, e.Y);

g.Clear(Color.White);

g.DrawRectangle(pen, r);

} } private void Form1_MouseUp(object sender, MouseEventArgs e) { doDraw = false;

} } } Результат выполнения программы представлен на рис. 2.

Рис. 2. Результат выполнения программы Самостоятельная работа 1. Начертить двойной прямоугольник.

2. Изменить цвет прямоугольника.

3. Изменить цвет фона 4. Изменить тип ограничительной линии Ответить на вопросы 11. Как вызвать свойства компонентов 12. Как исправить ошибки в программе 13. Какие виды сообщений от компилятора бывают 14. Как запустить программу на выполнение 15. Как создать проект 16. Основные компоненты проекта 17. Структурные части программного модуля 18. Описать процесс создания проекта 19. Структурные части проекта 20. Описать структуру меню.

Лабораторная работа № 4. Современные подходы к производству и обработке информации Цель: Изучение технологии программирования на языке C#.

Задачи:

1. Ознакомиться с теорией и научиться применять различные типы данных в среде Visual Studio.Net, на языке программирования C#.

2. Освоить создание структур данных и научиться применять различные способы их обработки Формируемые компетенции:

- навыки проектирования архитектуры и структуры прикладного алгоритма;

- навыки отладки и тестирования прикладного алгоритма в среде Visual Studio.Net на языке C#;

- навыки обработки структуры и абстракции данных Задание:

1. Изучите теорию и рассмотрите все примеры обработки данных.

2. Повторите основные структуры данных и соотнесите их с циклической структурой.

3. Используя локальные и глобальные переменные, операторы цикла (for, while…) напишите программу, которая выводит на экран номер итерации и значение глобальных переменных (имя глобальной и локальной переменной должны совпадать).

4. Реализуйте программу на языке программирования C# и получите результат работы прикладного алгоритма.

Теория:

Работа с консолью. Хотя время консольных приложений уходит, многие программы, не требующие взаимодействия с пользователем, остаются консольными. Также на таких программах удобно делать первые шаги. Поэтому, опишем основные приемы работы с консолью. Для работы с консолью в.NET используется класс Console. Удобство использование этого класса кроется в двух аспектах: все его методы являются статическими, так что не нужно создавать его экземпляр для использования. Во-вторых, он объединяет в себе ввод, вывод и вывод ошибок. По умолчанию ввод/вывод производится на стандартную консоль (если ее нет, например, в оконных приложениях, вывод просто не производится), но устройства ввода и вывода можно изменить.

Для работы с консолью обычно используется 4 метода: Read, ReadLine, Write и WriteLine. Первые два используются для ввода, последние - для вывода.

Метод Read Метод Read читает символ из потока ввода. Он возвращает значение типа int, равное коду прочитанного символа, либо -1, если ничего прочитано не было. Приведем пример программы:

do { int i = Console.Read();

if (i != -1) Console.WriteLine("{0} ({1})", (char)i, i);

else break;

} while (true);

Эта программа выводит на экран введенные символы и их коды.

Метод ReadLine Метод ReadLine читает из потока ввода строку текста (она завершается символом перевода строки или возврата каретки). Метод возвращает объект типа string или null, если ввод осуществить не удалось.

do { string s = Console.ReadLine();

if (s != null) Console.WriteLine("Введенная строка: " + s);

else break;

} while (true);

Методы Write и WriteLine Метод Write выводит на экран значение переданной ему переменной. Он определен для всех базовых типов и поддерживает форматированные строки. Таким образом, можно либо вызвать Write с указанным значением в качестве параметра:

Console.Write(1);

Console.Write(0.754);

Console.Write("Hello!");

Либо передать строку форматирования и список значений. В строке форматирования применяется множество модификаторов, здесь мы отметим лишь, что вмето "{n}" подставляется n-й входной параметр (нумерация начинается с 0):

Console.Write("Привет, {0}", Name);

Метод WriteLine отличается от Write только тем, что выводит символ перевода строки в конце.

Типы данных в C# Типы значения являются обычными типами данных, представляющими значения, например, целые числа для типа int. Но значения могут быть и более сложными - типы значений делятся на несколько групп. Это могут быть структуры, перечисления, числовые типы (которые, в свою очередь делятся на целые, вещественные и тип decimal) и булевый тип. Структуры являются аналогом классов, но в отличие от них являются типом значения.

То есть, значения типа структура передаются по значению, а не по ссылке. Есть и другие отличия, которые будут обсуждены позднее. Синтаксис для объявления структуры очень похож на объявление класса (структура описывает точку на плоскости):

public struct Point { public int x, y;

public Point(int p1, int p2) { x = p1;

y = p2;

} } Переменные типа перечисления могут принимать одно из заданных (перечисленных) значений. Значения задаются при определении типа. Также бывают битовые перечисления, в которых значения могут комбинироваться. Например, определим перечисление, описывающее время года:

public enum Season {Winter, Spring, Summer, Fall};

Для описания простых типов данных в C# сначала приведем сводную таблицу, а затем обсудим некоторые ее детали.

Целые типы Название Диапазон значений Размер типа Знаковое 8-битное sbyte -128.. целое Беззнаковое 8-битное byte 0.. целое 16-битный Unicode char U+0000..U+FFFF символ Знаковое 16-битное short -32.768..32. целое Беззнаковое 16-битное ushort 0. целое Знаковое 32-битное int -2.147.483.648..2.147.483. целое Беззнаковое 32-битное uint 0..4.294.967. целое Знаковое 64-битное long -9,223,372,036,854,775,808..9,223,372,036,854,775, целое Беззнаковое 64-битное ulong 0..18,446,744,073,709,551, целое Из особенностей отметим наличие 64-битных чисел и представление всех символов как Unicode (соответственно отсутствуют знаковые/беззнаковые символьные типы).

Типы с плавающей точкой Название типа Примерный диапазон значений Точность float +1.5E-45..+3.4E38 7 знаков double +5.0E-324..+1.7E308 15-16 знаков Тип decimal Decimal описывает 128-битный числовой тип. Он может быть как целым, так и вещественным с большой точностью, что делает его популярным для хранения денежных сумм.

Название типа Примерный Диапазон значений Точность decimal 1.0E-28 to 7.9E28 28-39 значащих цифр Все типы значений представлены соответствующими типами.NET Framework из пространства имен System. Они наследуются от класса ValueType. Для каждого типа значения поддерживается соответствующий "упакованный" (boxed) тип, который является классом, реализующим то же поведение и содержащим те же данные. Если требуется передать тип значения по ссылке, он автоматически упаковывается (box) в соответствующий упакованный тип, а по прибытии при необходимости распаковывается (unbox) снова в тип значения. Находясь в упакованном виде, тип может использовать все методы класса System.ValueType. Например, допустима следующая конструкция:

string s = 54.ToString();

При этом значение 54 упаковывается в класс System.Int32, который наследует от класса System.ValueType метод ToString(), который и вызывается.

Ссылочные типы представлены классами, делегатами и интерфейсами. Важнейшими представителями являются классы object и string (им соответствуют классы System.Object и System.String.NET Framework)/ Указатели доступны только в unsafe блоках и будут рассмотрены в соответствующей части.

Данные в C# хранятся в переменных соответствующего типа. C# является языком со строгой типизацией - значит, компилятор гарантирует, что переменная всегда имеет значение своего типа. В C# определено 7 типов переменных: статические, экземплярные, элементы массивов. Параметры, передаваемые по значению, выходные параметры и локальные переменные. Статическими переменными являются поля класса, объявленные с ключевым словом static. Их значение является общим для всех экземпляров класса.

Поясним сказанное на примере:

using System;

namespace StaticVariables { /// /// Класс Singleton реализует шаблон Singleton (одиночка).

/// Этот шаблон позволяет ограничивать количество /// экземпляров класса одним и обеспечивает к нему доступ.

/// class Singleton { /// /// Хранит единственный экземпляр класса /// private static Singleton _instance;

// Обеспечивает доступ к этому экземпляру public static Singleton Instance { get { // Если экземпляр не был создан, создаем его if (_instance == null) _instance = new Singleton();

return _instance;

} } /// /// Объявляем конструктор закрытым, чтобы не допустить создание /// дополнительных экземпляров /// private Singleton() { } /// /// Стандартный hello, world!

/// public void HelloWorld() { Console.WriteLine("Hello, world");

} } public class Application { public static void Main() { Singleton singleton = Singleton.Instance;

singleton.HelloWorld();

} } } В этом примере для доступа к статическому члену не нужно создавать экземпляра класса. Экземплярные переменные - это поля класса, значения которых для каждого экземпляра индивидуальны.

using System;

namespace InstanceVariables { /// /// Этот класс хранит имя мужчины /// class Man { /// /// Хранит обращение - общее для всех экземпляров /// private static string _prefix = "Mr.";

/// /// Хранит имя каждого отдельного мужчины /// public string _name;

/// /// Создает мужчину с заданным именем /// /// Имя public Man( string name ) { _name = name;

} /// /// Меняет обращение для всех мужчин /// /// Новое обращение public void ChangePrefix( string prefix ) { _prefix = prefix;

} /// /// Выводит строковое представление экземпляра /// /// Возвращает строковое представление public override string ToString() { return _prefix + " " + _name;

} } public class Application { public static void Main() { // Создаем двух мужчин с разными именами Man smith = new Man("Smith");

Man pitt = new Man("Pitt");

// Выводим их начальные состояния Console.WriteLine("До изменения: " + smith + ", " + pitt);

// Изменяем имя одного из них pitt._name = "Pumpkin";

Console.WriteLine("После изменения имени одного из них: " + smith + ", " + pitt);

// Меняем обращение pitt.ChangePrefix("Dr.");

Console.WriteLine("После изменения обращения: " + smith + ", " + pitt);

} } } Вот вывод программы:

До изменения: Mr. Smith, Mr. Pitt После изменения имени одного из них: Mr. Smith, Mr. Pumpkin После изменения обращения: Dr. Smith, Dr. Pumpkin Как видно из вывода, в первый раз меняется значение только для одного экземпляра, а во второй - для всех. Также отметим, что статические и экземплярные переменные автоматически инициализируются значением по умолчанию.

Массивы Массивы в C# очень просты и похожи на массивы в C++. В C# имеется три основных типа массивов: одномерные, многомерные и неровные(jagged):

Одномерные массивы:

Декларация/ Декларируются они также как в C++:

int[] array = new int[10];

int[] array = {1, 2, 3, 4, 5};

Доступ Доступ к элементам производится с помощью оператора []:

int element = array[0];

Элементы нумеруются индексами от 0 до N - 1, где N - размер массива.

Многомерные массивы / Представляют собой многомерные кубы значений. Элементы таких массивов идентифицируются набором индексов - "координат" в многомерном пространстве.

Каждое измерение имеет свою размерность, не зависящую от других. Отметим, что многомерные массивы являются важным отличием от других подобных языков (Java), ибо по сравнению с неровными массивами, обеспечивают гораздо большую производительность.

Декларация/ При декларации размерности измерений указывается через запятую:

int[,] array = new int[10, 20];

int[,] array = {{1, 2}, {3, 4}};

Доступ Доступ к элементам производится с помощью оператора [], в котором индексы также указываются через запятую:

int element = array[0, 2];

Элементы нумеруются наборами индексов, каждый из которых может принимать значение от 0 до N - 1, где N - размер соответствующего измерения массива.

Неровные (jagged) массивы Это, по сути, массивы массивов. Собственно, формы декларации и доступа вытекают из этого:

Декларация int array[][] = new int[2][];

array[0] = new int[4];

array[1] = new int[20];

Доступ int element = array[0][1];

Неровные массивы похожи на многомерные, но их размеры могут различаться даже в одном измерении. В приведенном примере существует элемент array[1][15], но не существует элемента array[0][15].



Pages:     | 1 | 2 || 4 | 5 |
 





 
© 2013 www.libed.ru - «Бесплатная библиотека научно-практических конференций»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.