Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Лекция 1
1.Общие положения о стандартах. Понятие стандартизации. Стандартиза- ция — это деятельность, направленная на разработку и установление требований, норм, правил, характерис тик, как обяза- тельных для выполнения, так и рекомен- дуемых, обеспечивающая право потреби- теля на приобретение товаров надлежаще- го качества, а также право на безопасность и комфор тность труда. Цель стандарти- зации — достижение оптимальной степени упорядочения в той или иной области по- средством ши рокого и многократного ис- пользования установленных положе ний, требований, норм для решения реально существующих, планируемых или потен- циальных задач. Основными результата- ми деятельности по стандартизации должны быть повышение степени соответ- ствия продукта (услуги), процессов их функцио нальному назначению, устране-
ние технических барьеров в меж дународ- ном товарообмене, содействие научно- техническому про грессу и сотрудничеству в различных областях. Стандартизация связана с такими по- нятиями, как объект стан дартизации и об- ласть стандартизации. Объектом стандар- тиза ции обычно называют продукцию, процесс, услугу, для которых разрабаты- вают те или иные требования, характери- стики, пара метры, правила и т.п. Стандар- тизация может касаться либо объек та в целом, либо его отдельных составляющих (характеристик). Областью стандартиза- ции называют совокупность взаимосвязан ных объектов стандартизации. Стандартизация осуществляется на разных уровнях. Уровень стандартизации зависит от того, участники какого геогра- фичес кого, экономического, политическо- го региона мира принимают стандарт. Ес- ли участие в стандартизации открыто для соответ ствующих органов любой страны, то это международная стан дартизация. Ре-
гиональная стандартизация — деятель- ность, от крытая только для соответству- ющих органов государств одного геогра- фического, политического или экономиче- ского региона. Региональная и междуна- родная стандартизация осуществляется специалистамистран Национальная стан- дартизация — стандартизация в одном кон кретном государстве. При этом националь- ная стандартизация так же может осу- ществляться на разных уровнях: на госу- дарственном, отраслевом, в том или ином секторе экономики (например, на уров не министерств), на уровне ассоциаций, про- изводственных фирм, предприятий (фаб- рик, заводов) и учреждений. Стандартизацию, которая проводится в административно-территориальной еди- нице (провинции, крае и т.п.), принято на зывать административно- территориальной стандартизацией.
2.Нормативные документы по стан- дартизации. Виды стандартов В процессе
стандартизации вырабатываются нормы, правила, требования, характеристики, ка- сающиеся объекта стандартизации, кото- рые оформляются в виде нормативного документа. Руководство ИСО/МЭК рекомендует: стандарты, документы технических ус- ловий, своды правил, регламенты (техни- ческие регламенты), положения (рис. 1.2).Стандарт (от англ. standard — норма, образец) — в широком смысле слова обра- зец, эталон, модель, принимаемые за ис- ходные для сопоставления с ними других подобных объектов. Стандарт как норма- тивно-технический документ устанавлива- ет комплекс норм, правил, требований к объекту стандартизации. Стандарт может быть разработан как на материальные предметы (продукцию, эталоны, образцы веществ), так и на нормы, правила, требо- вания в различных областях. В переносном смысле — шаблон, трафарет, не содержа- щий ничего оригинального. Стандарт — это нормативный доку-
мент, разработанный на основе консенсуса, утвержденный признанным органом, направленный на достижение оптимальной степени упорядочения в определенной об- ласти. В стандарте устанавливаются для всеобщего и многок]рат-ного использова- ния общие принципы, правила, характери- стики, касающиеся различных видов дея- тельности или их результатов. Стандарт должен быть основан на обобщенных ре- зультатах научных исследований, техниче- ских достижений и практического опыта, тогда его использование принесет опти- мальную выгоду ДДЯ общества. Предварительный стандарт — это временный документ, который принимает- ся органом по стандартизации и доводится до широкого круга потенциальных потре- бителей, а также до тех, кто может его применить. Информация, полученная в процессе использования предварительного стандарта, и отзывы об этом документе служат базой для решения вопроса о целе- сообразности принятия стандарта.
Стандарты бывают международными, региональными, национальными, админи- стративно-территориальными. Они прини- маются соответственно международными, региональными, национальными, террито- риальными органами по стандартизации. Все эти категории стандартов предназна- чены для широкого круга потребителей. По существующим нормам стандартизации стандарты периодически пересматривают- ся для внесения изменений, чтобы их тре- бования соответствовали уровню научно- технического прогресса, или, согласно тер- минологии ИСО/МЭК, стандарты должны представлять собой «признанные техниче- ские правила». Нормативный документ, в том числе и стандарт, считается признан- ным техническим правилом, если он разра- ботан в сотрудничестве с заинтересо- ванными сторонами путем консультаций и на основе консенсуса.
Документ технических условий (technical specification) устанавливает тех-
нические требования к продукции, услуге, процессу. Свод правил, как и предыдущий нор- мативный документ, может быть самосто- ятельным стандартом либо самостоятель- ным документом, а также частью стандар- та.. Кроме стандартов нормативными до- кументами являются также ПР — правила по стандартизации, Р — рекомендации по стандартизации и ТУ — технические усло- вия. . Отраслевые стандарты разрабатыва- ются применительно к продукции опреде- ленной отрасли. Объектами отраслевой стандартиза- ции могут быть: • продукция, процессы и услуги, при- меняемые в отрасли; • правила, касающиеся организации работ по отраслевой стандартизации; • типовые конструкции изделий от- раслевого применения (инструменты, кре-
пежные детали и т.п.); • правила метрологического обеспече- ния в отрасли. Диапазон применяемости отраслевых стандартов ограничивается предприятия- ми, подведомственными государственному органу управления, принявшему данный стандарт. Стандарты предприятий разрабаты- ваются и принимаются самими предприя- тиями. Объектами стандартизации в этом случае обычно являются составляющие подсистем организации и управления про- изводством, совершенствование которых — главная цель стандартизации на данном уровне. Закон РФ «О стандартизации» реко- мендует использовать стандартизацию на предприятии для освоения данным кон- кретным предприятием государственных, международных, региональных стандартов, а также для регламентирования требований к сырью, полуфабрикатам и т.п., закупае- мым у других организаций. Эта категория
стандартов обязательна для предприятия, принявшего этот стандарт. Но если в дого- воре на разработку, производство, постав- ку продукта или предоставление услуг име- ется ссылка на стандарт предприятия, он становится обязательным для всех субъек- тов хозяйственной деятельности — участ- ников такого договора. Правила и рекомендации по стандар- тизации по своему характеру соответству- ют нормативным документам методиче- ского содержания. Технические условия разрабатывают предприятия и другие субъекты хозяй- ственной деятельности в том случае, когда стандарт создавать нецелесообразно. Объ- ектом ТУ может быть продукция разовой
3.Классификация стандартов в обла- сти программного обеспечения. Стандарты имеют большое значение — они обеспечивают возможность разра- ботчикам программного обеспечения ис-
пользовать данные и программы других разработчиков, осуществлять экс- порт/импорт данных. Такие стандарты регламентируют вза- имодействие между различными програм- мами. Для этого предназначены стандарты межпрограммного интерфейса, например OLE (Object Linking and Embedding — свя- зывание и встраивание объектов разработаны стандарты на пользова- тельский интерфейс — GUI (Graphical User Interface). Все это регламентируется стан- дартами, действующими в сфере инфор- мационных технологий. Необходимость стандартизации раз- работки программного обеспечения наиболее удачно описана во введении в стандарт ISO/ IEC 12207: Стратегия разра- ботки программного обеспечения требует перехода от этого множества к общему по- рядку, который позволит специалистам, практикующимся в программном обеспе- чении, «говорить на одном языке» при разработке и управлении программным
обеспечением. Этот международный стан- дарт обеспечивает такой общий порядок». Классиф-я: Ст-ты: 1)в зав-ти от мас- штаба (междунар-ые, нац-ые, отраслевые, внутрифирменные), 2)в зав-ти от возник- ия («де-факто» и «де-юре»). От них идут Ст-т на орган-ию ЖЦ: 1)ст-ты обеспечения кач-ва, 2)ст-ты надѐжности, 3)ст-ты разра- ботки ПО (ст-ты интерфейса, ст-ты про- грам-ия, ст-ты обмена данными), 4)ст-ты тестирования, 5)ст-ты документирования. С ними связаны Модели разработки: 1)RUP, 2)Tickit, 3)CMM, 4)Метод Oracle (CDM, PJM, AIM, BPR, DWM), 5) IEEE Software Engineering standarts, 6) IEEE/EIA 12207, 7) Cleanroom software engineering model. .
ЛЕКЦИЯ 2
4.Стандарты «де-факто» и «де-юре». Стандарт «де-факто» — термин, обо- значающий продукт какого-либо поставщи- ка, который захватил большую долю рынка и который другие поставщики стремятся эмулировать, копировать или использовать для того, чтобы захватить свою часть рынка. Одна из главных причин значимости современной программы стандартизации — осознание опасности злоупотребления стан- дартами «де-факто». В 60-е и 70-е годы XX века создание стандартов «де-факто» ста- вило пользователей в зависимое от про- изводителей положение при использовании основных средств обработки данных и теле- коммуникаций. Важный аспект сегодняш- ней работы по стандартизации — преодоле- ние этой зависимости через продвижение стандартных интерфейсов. Долгое время та кими стандартами были SQL (Structured Query Language) и язык диаграмм Д. Росса SADT (Structured Analysis and Design Tech-
nique). Стандарт «де-юре» создается формаль- но признанной стандартизующей организа- цией. Он разрабатывается при соблюдении правил консенсуса в процессе открытой дис- куссии, в которой каждый имеет шанс при- нять участие. Ни одна группа не может дей- ствовать независимо, создавая стандарты для промышленности. Если какая-либо группа поставщиков создаст стандарт, не учитыва- ющий требования пользователей, она потер- пит неудачу. То же самое происходит, если пользователи создают стандарт, с которым не могут или не будут соглашаться постав- щики, — этот стандарт также не будет успешным. Стандарты «де-юре» не могут быть изменены, не пройдя процесс согласо- вания под контролем организации, разра- батывающей стандарты. Стандарты OSI (Open Systems Interconnection reference mod- el), Ethernet, POSIX, SQL и большинство стандартов языков — примеры такого рода стандартов.
6.Международные организации, раз- рабатывающие стандарты. Международ- ная организация по стандартизации (ИСО). Международная организация по стан- дартизации создана в 1946 г. двадцатью пя- тью национальными организациями по стандартизации. При создании организации и выборе ее названия учитывалась необходимость того, чтобы аббревиатура наименования звучала одинаково на всех языках. Для этого было решено использовать греческое слово «isos» — равный. Вот почему на всех языках мира Международная организация по стандарти- зации имеет краткое название ISO (ИСО). Сфера деятельности ИСО касается стандартизации во всех областях, кроме электротехники и электроники, относящих- ся к компетенции Международной электро- технической комиссии (МЭК). Некоторые виды работ выполняются совместными уси- лиями этих организаций. Кроме стандарти- зации ИСО занимается и проблемами сер-
тификации. ИСО определяет свои задачи следую- щим образом: содействие развитию стан- дартизации и смежных видов деятельности в мире с целью обеспечения международно- го обмена товарами и услугами, а также развития сотрудничества в интеллектуаль- ной, научно-технической и экономической областях. Вопросы информационной технологии, микропроцессорной техники и т.п. входят в область совместных разработок ИСО/ МЭК. В последние годы ИСО уделяет много вни- мания стандартизации систем обеспечения качества. Практическим результатом усилий в этих направлениях являются разработка и издание международных стандартов. При их разработке ИСО учитывает ожидания всех заинтересованных сторон — производите- лей продукции (услуг), потребителей, пра- вительственных кругов, научно- технических и общественных организаций. На сегодняшний день в состав ИСО входят 120 стран своими национальными
организациями по стандартизации. Россию представляет Госстандарт РФ в качестве комитета — члена ИСО. Всего в составе ИСО более 80 комитетов-членов. Кроме ко- митетов- членов членство в ИСО может иметь статус членов-корреспондентов, ко- торыми являются организации по стандар- тизации развивающихся государств. Довольно широки деловые контакты ИСО: с ней поддерживают связь около 500 международных организаций, в том числе все специализированные агентства ООН, работающие в смежных направлениях. ИСО поддерживает постоянные рабо- чие отношения с региональными организа- циями по стандартизации. Практически чле- ны таких организаций одновременно явля- ются членами ИСО. Поэтому при разработ- ке региональных стандартов за основу при- нимается стандарт ИСО нередко еще на стадии проекта. Наиболее тесное сотрудни- чество поддерживается между ИСО и Ев- ропейским комитетом по стандартизации (СЕН).
Крупнейший партнер ИСО — Между- народная электротехническая комиссия (МЭК). В целом эти три организации охва- тывают международной стандартизацией все области техники. Кроме того, они ста- бильно взаимодействуют в области инфор- мационных технологий и телекоммуника- ции. Международные стандарты ИСО не имеют статуса обязательных для всех стран- участниц. Любая страна мира вправе приме- нять или не применять их. Решение вопроса о применении международного стандарта ИСО связано в основном со степенью уча- стия страны в международном разделении труда и состоянием ее внешней торговли. 7.международные организации, разра- батывающие стандарты. Международная электротехническая комиссия.
Международная электротехническая комиссия создана на международной кон- ференции, в работе которой участвовали 13 стран, в наибольшей степени заинтересо-
ванных в такой организации. Датой начала международного сотрудничества по элек- тротехнике считается 1881 г., когда состо- ялся первый Международный конгресс по электричеству. Позже, в 1904 г., правитель- ственные делегаты конгресса решили, что необходима специальная организация, ко- торая бы занималась стандартизацией пара- метров электрических машин и терминоло- гией в этой области. После второй мировой войны, когда была создана ИСО, МЭК стала автономной организацией в ее срставе. МЭК занимается стандартизацией в области электротехники, элект связи, приборостроения. Эти области не входят в сферу деятельности ИСО [48].
Авторитетная всемирная органи- зация, обеспечивающая разработку еди- ных стандартов в области электротехни- ки, электроники, телекоммуникацион- ных, информационных технологий, их взаимосогласованность, гармонизацию на основе добровольного принятия и
применения в интересах: прогресса общества; распространения современных зна- ний; расширения применения сертифи- кации; развития международной торговли. Разрабатывает международные стандарты с 1906 года. Членами являются 53 страны, в которых проживает 85 %населе- ния земного шара которые производят 95 % всей электроэнергии, на долю которых приходится по- давляющий объем мировой торговли. Состоит из 87 технических комите- тов и 96 подкомитетов, которые обеспечи- вают разработку стандартов по конкретным видам продукции и охватывают практиче- ски весь спектр электротех-нической и электронной продукции, разрабатывая такие проблемы как терминология, условные обо- значения, безопасность, технические харак-
теристики и эксплуатационные качества. Издано и действует свыше 4000 стандартов общим объемом около 170000 страниц. В каждой стране-члене МЭК дей- ствует свой национальный Комитет. Прези- денты всех национальных комитетов входят в состав руководящих органов МЭК. Общепризнан тот факт, что приня- тие и применение стандартов МЭК ос- новными индустриальными странами способствует развитию международной торговли электронными и электротехни- ческими товарами и обеспечивает про- мышленному сектору высочайшие темпы экономического роста.
Зачем нужны ГОСТ 19 и ГОСТ 34
В нашей стране госты серий 19 и 34 ча- сто применяются при создании программ и автоматизированных систем, особенно, ко- гда в качестве заказчиков выступают госу- дарственные или крупные коммерческие ор- ганизации. Стандарты эти таковы, что руко- водители проектов и разработчики техниче- ской документации, сталкиваясь с ними впервые, обычно приходят в замешатель- ство. Отчасти это связано с объемом стан- дартов и своеобразием употребляемой в них терминологии, но в первую очередь наверно все-таки с тем, что начинающие не видят с сла в стандартизированной технической до- кументации. У них складывается впечатле- ние, что госты — бюрократическое наследие Советского Союза, по недоразумению про- должающее отравлять нам жизнь. Задача в том, чтобы очертить область действия 19-х и 34-х гостов и объяснить, для чего они нуж- ны. Содержания гостов касаться не будем.
Программы и автоматизированные си- стемы Бывают программы, а бывают автома- тизированные системы. Еще бывают аппа- ратно-программные комплексы и много раз- ных других видов продукции. Под программой обычно подразумева- ют машинный код (часто еще добавляют, представленный в объективной форме), ко- торый может быть выполнен компьютером. Если вы на языке PHP написали скрипт, формирующий страничку с надписью «Сла- ва труду!», то вы произвели на свет про- грамму. Вы можете поместить эту програм- му в подходящие условия, например, на компьютер, где уже функционируют интер- претатор PHP и какой-нибудь HTTP-сервер, и она будет работать. Если к тому же вы до- пускаете применение этого скрипта более- менее широким кругом лиц и обеспечили им такую возможность, то получился про- граммный продукт. Теперь представим себе, что Министер- ство труда и занятости решило в целях по- вышения трудолюбия населения страны со-
здать сайт, на главной странице которого при загрузке отображается какой-нибудь полезный лозунг. Для этого оно делает сле- дующее: - выделяет в здании министерства каби- нет; - ставит в этот кабинет компьютер и подключает его к Интернету; - устанавливает на этот компьютер HTTP-сервер Apache, интерпретатор PHP и ваш скрипт; - вменяет в обязанность кому-нибудь из сотрудников раз в неделю менять текст ло- зунга. В результате этой работы возникает ав- томатизированная система. Что она в себя включает? Прежде всего, наблюдаем целе- направленную автоматизированную дея- тельность, в данном случае пропагандист- скую работу. Осуществляет ее назначенный для этого персонал, пускай даже в количе- стве одного человека. Наконец, у системе есть технические средства (компьютер) и программное обеспечение (операционная система, интерпретатор PHP, HTTP-сервер
Apache и скрипт). Вообще говоря, автомати- зированная система может включать в себя много чего еще, но четыре перечисленные составляющие обязательны, иначе это не ав- томатизированная система.
Участники разработки В процессе создания программы или автоматизированной системы всегда обяза- тельно есть три роли: разработчик, заказчик и пользователь. Это утверждение может по- казаться странным, потому что если фирма производит программный продукт и продает его в магазине, то какой же там заказчик? И какое участие в его создании программного продукта или автоматизированной системы принимает пользователь? Какой-то заказчик есть всегда. В ком- пании, которая выпускает программные продукты, эта функция возлагаются на со- трудников, например, на менеджеров по продуктам, выставляющих производствен- ным подразделениям внутренний заказ. На практике это далеко не всегда соблюдается, но тогда довольно быстро разработка при-
ходит в состояние, именуемое в просторе- чии бардаком. То же самое касается разра- ботки автоматизированной системы силами организации для собственных нужд. Участ- ников необходимо поделить на две команды, разработчиков и заказчиков. Иначе вместо целенаправленной работы по созданию си- стемы получится тот самый ремонт, кото- рый, по словам классика, нельзя закончить, а можно только прекратить. Случается, что пользователи принима- ют непосредственное участие в разработке программ и автоматизированных систем. Аналитики могут опрашивать их на стадии формирования требований, пользователи могут принимать участие в тестировании и т.п. Но это не главное. Гораздо важнее, что программные продукты и системы разраба- тываются на базе многочисленных в разной степени обоснованных предположений о це- лях, задачах, свойствах и действиях пользо- вателей. Образно говоря, пользователь оста- ется за кадром, но на всем видим его ги- гантскую тень.
Типы и функции технической докумен- тации Абстрагируясь от различий между раз- ными стандартами, методологиями и други- ми источниками знания, можем сказать, что развитие любой продукции проистекает сле- дующим образом: - заказчик и разработчик решают, что и зачем они собираются создать; - разработчик создает, а заказчик при- нимает продукцию; - результат передается пользователю для целевого применения. Исходя из этого техническую докумен- тацию можно условно разделить на два ти- па: документацию разработки и документа- цию продукции. Документацией разработки обмениваются друг с другом непосред- ственные участники этой деятельности. До- кументацию продукции передают пользова- телю (в широком смысле), чтобы он мог применять программу или автоматизиро- ванную систему по назначению. Некоторые стандарты выделяют еще третий тип: доку- ментацию управления проектом, но это до-
кументы скорее организационно- распорядительного, чем технического ха- рактера, и здесь их рассматривать не бу- дем. Очевидная функция технической доку- ментации — сохранение и передача всевоз- можных сведений технического характера. Из этих соображений техническая докумен- тация должна быть как можно более понят- ной, информативной, удобной и т.п. Форма- лизовать эти качества сложно, но можно, существуют стандарты и методики, в кото- рых это с большим или меньшим успехом делается. Другая важная функция технической документации нормативная. Техническая документация при должном ее оформлении (например, в качестве приложения к догово- ру на создание программы или автоматизи- рованной системы ) фиксирует взаимные обязательства участников разработки. Госты серий 19 и 34 в значительной мере направ- лены на то, чтобы техническая документа- ция эффективно работала в этом качестве.
Стандартизация документации разра- ботки Разработка программ и автоматизиро- ванных систем — это не вечеринка, которая может оказаться удачной или не очень, но в конце концов все разъедутся по домам, а сложная, продолжительная и дорогостоящая деятельность, в которую вовлечены разные организации (или их подразделения), специ- алисты, начальники разного ранга. У них есть свои групповые и персональные инте- ресы. Если что-то пойдет не так, например, на программный продукт не окажется спро- са, или внедрение автоматизированной си- стемы провалится, то пострадавшие при- мутся искать виноватого, а когда найдут, попытаются получить с него моральную и материальную компенсацию в максимально возможном размере. Поскольку оказаться крайним и «остаться без штанов» обычно никто не хочет, каждый заинтересован в как можно более четком ограничении собствен- ной зоны и меры ответственности. На уровне финансов, сроков, имущественных прав и т.п. взаимные обязательства фикси-
руются в договорах. На содержательном уровне — в технической документации. По завершении каждой стадии создания программы или автоматизированной систе- мы заказчик и разработчик фиксируют по- лученные результаты в технической доку- ментации и утверждают последнюю. Это линия отреза. После того, как техническая документация утверждена, пересмотр ее со- держания заказчиком или разработчиком в одностороннем порядке юридически невоз- можен. Пример 1. Если в утвержденном техни- ческом задании (ТЗ) на автоматизированную систему сказано, что посетитель сайта дол- жен видеть лозунг «Слава труду», заказчик не имеет права вдруг потребовать еще и де- монстрации рекламного ролика на эту тему. Вполне возможно, что показывать ролик — неплохая идея, но заказчику следовало вы- сказать ее раньше, когда разработчик согла- совывал с ним техническое задание. С дру- гой стороны, если вместо положенного тек- ста система будет выдавать рекламу ночного клуба, у заказчика появятся все основания
потребовать от разработчика внесения в си- стему необходимы х изменений, и не пла- тить ему денег, пока система не будет при- ведена в соответствие техническому зада- нию. Пример 2. Если в утвержденном техни- ческом проекте зафиксировано, что для реа- лизации автоматизированной системы ис- пользуется скрипт на PHP , разработчик не имеет права огорошить заказчика предложе- нием вместо бесплатного интерпретатора этого языка приобрести Lotos Domino. Но, с другой стороны, и заказчик не может потре- бовать от разработчика вместо нормального сервера использовать компьютер БК 0010, завалявшийся в кладовке с советских вре- мен. Бюрократически правильное ведение технической документации заставляет всех участников разработки вести себя предска- зуемо по отношению друг к другу, что ко- нечном счете, всем выгодно, несмотря на дополнительные затраты. Ведение техниче- ской документации позволяет предотвратить многие недоразумения и злоупотребления. В
том случае, если заказчик и разработчик так испортят отношения, что дело дойдет до ар- битража, техническая документация будет служить для ущемленной стороны сред- ством доказать свою правоту. Без техниче- ской документации вероятность и болезнен- ность всевозможных склок и «разборок» сильно повышается. Всякая бюрократизация подразумевает соблюдение определенных форм. Формы договоров и основных финансовых доку- ментов продиктованы законодательством. Аналогично, формы технических докумен- тов продиктованы ГОСТами. При этом тех- ническая документация на программы опи- сывается Единой системой программной до- кументации (ГОСТ 19), а техническая доку- ментация на автоматизированные системы Комплексом стандартов на автоматизиро- ванные системы (ГОСТ 34).
Стандартизация документации продук-
ции
Документация продукции (или, иными словами, эксплуатационная документация)
фактически представляет собой часть этой продукции, поскольку без нее целевое при- менение последней невозможно или сильно затруднено. Стандартизация эксплуатацион- ной документации позволяет не описывать в договоре или в техническом задании по- дробные требования к эксплуатационной документации, а сослаться на соответству- ющие стандарты или их разделы. Требова- ния к составу и содержанию эксплуатацион- ной документации на программу приведены в гостах серии 19. Требования к составу и содержанию эксплуатационной документа- ции на автоматизированную систему приве- дены в гостах серии 34.
Обязательность соблюдения гостов В России действует федеральный закон «О техническом регулировании», в соответ- ствии с которым соблюдение стандартов (за исключением некоторых) дело доброволь- ное. Хорошо ли это, вопрос второй, но на момент написания данной статьи дело об- стоит именно так. Соблюдение определен- ного стандарта становится обязательным для
заказчика и разработчика, если они включа- ют это условие в договор. Правда, ограни- чиваться одним этим условием опасно, в са- мом договоре или в каком-нибудь из прило- жений к нему полезно привести более чет- кие требования к технической документа- ции, но это уже другая тема.
ОРГАНИЗАЦИЯ ДИПЛОМНОГО ПРОЕКТИРОВАНИЯ СТРУКТУРА И ПРАВИЛА ОФОРМЛЕНИЯ ПОЯСНИТЕЛЬНОЙ ЗАПИСКИ ДИПЛОМНОЙ РАБОТЫ
Методические рекомендации для специальности 080801 «Прикладная информатика ( в экономике )»
3 Общие положения 3.1 Дипломное проектирование являет- ся заключительным этапом обучения сту- дентов в институте … 3.3 Студентам предоставляется право выбора темы дипломной работы . Студент может предложить для дипломной работы тему с необходимым обоснованием целесо- образности ее разработки . 3.4 Темы дипломных работ и руководи- тели утверждаются приказом ректора не позднее , чем за 1-2 недели до начала пред- дипломной практики .
3.8 Студент , имеющий академическую задолженность , к дипломному проектирова- нию не допускается . 3.9 Дипломник несет личную ответст- венность за качество и своевременное пред- ставление выполненного в полном соответ- ствии с заданием проекта к защите . 3.13 Законченная дипломная работа , подписанная студентом , руководителем и консультантами представляется студентом заведующему кафедрой . Вместе с диплом- ной работой на кафедру представляется письменный отзыв руководителя . В отзыве должна быть отражена как общая характе- ристика проделанной работы , так и конкрет- ная оценка работы в целом (« отлично », « хо- рошо », « удовлетворительно », « неудовле- творительно »). 3.14 Дипломная работа , допущенная к защите , направляется на рецензию .
4 Требования к структуре дипломной работы Введение (5-7 страниц )
Во введении дается краткая характери- стика проблемы , рассматриваемой в ди- пломной работе . Излагаются очередные за- дачи в области дальнейшей разработки про- блемы , формулируются ожидаемые резуль- таты . ОСНОВНАЯ ЧАСТЬ Глава 1 Анализ состояния вопроса (25- 30 страниц ) 1.1 В главе дается анализ проблемы на основе научно -технической литературы . Рассматриваются экономические аспекты проблемы , приводится анализ их решения с применением информационной системы (20- 25 страниц ). 1.2 Постановка задачи исследования . Формулируются основные проблемы для выбранного объекта исследования . Указы- ваются возможные пути решения . Выбира- ется оптимальный путь . Формулируются за- дачи , решение которых позволит решить по- ставленную проблему (5-10 страниц ). Глава 2 Практическая часть (25-35 страниц )
2.1 Теоретическое решение поставлен- ных задач . 2.2 Практическое решение для выбран- ного объекта с использованием информаци- онных систем . 2.3 Практическое применение и эффек- тивность полученных результатов для вы- бранного объекта . Глава 3 Социально -экономическая эф- фективность выполненной работы (7-10 страниц ) Приводится расчет прямого экономиче- ского эффекта от использования информа- ционной системы , обсуждаются особенно- сти косвенного экономического эффекта . Заключение (1-2 страницы ) Формулируется общий итог поставлен- ной проблемы . Приводится перечень основ- ных результатов , полученных в ходе выпол- нения работы . Список использованных источников (15-30 наименований ). Структура и правила оформления пояс- нительной записки дипломной работы в со-
ответствии с требованиями к научно - исследовательским отчетам по ГОСТ 7.32. Структурными элементами дипломной работы являются : Пояснительная записка дипломного проекта должна содержать : - ТИТУЛЬНЫЙ ЛИСТ ; - РЕФЕРАТ ; - СОДЕРЖАНИЕ ; - ВВЕДЕНИЕ ; - ОСНОВНУЮ ЧАСТЬ в соответствии с утвержденным заданием на дипломный про- ект ; - ЗАКЛЮЧЕНИЕ ; - СПИСОК ИСПОЛЬЗОВАННЫХ ИС- ТОЧНИКОВ ; - ПЕРЕЧЕНЬ СОКРАЩЕНИЙ , УСЛО- ВНЫХ ОБОЗНАЧЕНИЙ , ЕДИНИЦ , СИМ- ВОЛОВ И ТЕРМИНОВ ; - ПРИЛОЖЕНИЯ . (ПРИЛОЖЕНИЕ А – Задание на проек- тирование )
5 Требования к структурным элемен- та дипломной ра- боты
5.2 Задание В бланке задания приводят следующие сведения : 1) наименование организации ; 2) гриф утверждения дипломной рабо- ты ; 3) номер задания по приказу ; 4) специальность ; 5) номер группы , фамилия , имя , отчест- во студента ( в дательном падеже ); 6) тема дипломной работы ; 7) число и номер приказа ректора об утверждении темы дипломной работы ; 8) срок исполнения дипломной работы ; 9) подпись , фамилия и инициалы ис- полнителя дипломной работы ; 10) место и дата составления диплом- ной работы . На следующей странице приводят ис- ходные данные дипломной работы , наиме- нование разделов дипломной работы , фами- лии , инициалы и подписи консультантов разделов дипломной работы .
На втором листе бланка задания даются рекомендации руководителя дипломной ра- боты по просмотру реферативных и научно - технических журналов , ставится подпись и фамилия руководителя дипломной работы . Лист бланка задания изображен в ПРИ- ЛОЖЕНИИ Б.
5.3 Реферат 5.3.1 Общие требования к реферату по ГОСТ 7.9. 5.3.2 Реферат должен содержать : 1) сведения об объеме дипломной рабо- ты , количестве слайдов , количестве иллюст- раций , таблиц , приложений , количестве ис- пользованных источников ; 2) перечень ключевых слов ; 3) текст реферата . 5.3.2.1 Перечень ключевых слов должен включать слова из текста работы , которые в набольшей мере характеризуют ее содержа- ние и обеспечивают возможность информа- ционного поиска . Перечень ключевых слов должен содержать от 5 до 15 слов или сло- восочетаний из текста работы . Ключевые
слова приводятся в именительном падеже и печатаются строчными буквами в строку че- рез запятые . 5.3.2.2 Текст реферата должен отра- жать : 1) объект исследования или разработки ; 2) цель работы ; 3) метод исследования ; 4) полученные результаты и их новизну ; 5) степень внедрения ; 6) рекомендации по внедрению или ито- ги внедрения результатов работы ; 7) область применения ; 8) экономическую эффективность ; 9) прогнозные предположения о разви- тии объекта исследования . Общий объем реферата должен быть не более 2/3 страницы .
5.4 Содержание 5.4.1 Содержание включает введение , наименование всех разделов , подразделов , пунктов ( если они имеют наименование ) и заключение с указанием номеров страниц , с
которых начинаются эти элементы диплом- ной работы . 5.4.2 Принятые в работе сокращения , условные обозначения , символы и специфи- ческие термины должны быть представлены в виде отдельного списка . 5.4.3 Если сокращения повторяются в работе менее трех раз , отдельный список не составляют , а расшифровку дают непосред- ственно в тексте при первом упоминании .
5.5 Введение Введение должно содержать оценку со- временного состояния решаемой проблемы , основание и исходные данные для разработ- ки темы , обоснование необходимости про- ведения разработки . Во введении должны быть показаны актуальность и новизна темы дипломной работы .
5.6 Основная часть Основная часть должна содержать : 1) выбор направления исследований , включающий обоснование выбора принято- го направления , методы решения задач ;
2) теоретические и экспериментальные исследования , предложения по дальнейшим направлениям работ ; 3) социально -экономическую эффек- тивность выполненной работы . Основная часть делится на разделы и пункты . Разделы основной части делятся на подразделы и пункты . Пункты могут де- литься на подпункты . Каждый пункт дол- жен содержать законченную информацию .
5.7 Заключение Заключение должно содержать краткие выводы по результатам выполненной рабо- ты , оценку полноты решений поставленной задачи , оценку экономической эффективно- сти внедрения .
5.8 Список использованных источни-
ков
В список использованных источников включаются все источники , использованные при выполнении дипломной работы . Сведе- ния об источниках даются в соответствии с требованиями ГОСТ 7.1.
5.9 Перечень сокращений , условных обозначений , единиц , символов и терми- нов Перечень содержит сокращения , усло- вные обозначения, единицы, символы и тер- мины. Принятые в отчете малораспростра- ненные сокращения , условные обозначения , символы , единицы и специфические терми- ны должны быть представлены в виде от- дельного списка . Если сокращения , услов- ные обозначения , символы , единицы и тер- мины повторяются в отчете менее трех раз , отдельный список не составляют , а расшиф- ровку дают непосредственно в тексте отчета при первом упоминании .
5.10 Приложения Первой , второй и третьей страницей ПРИЛОЖЕНИЯ А идут бланки задания на проектирование . Пример оформления блан- ков см . в ПРИЛОЖЕНИИ Б В приложениях к пояснительной запис- ке должны помещаться материалы вспомо- гательного характера , которые при включе-
нии в основную часть текста загромождают его . К таким материалам могут быть отнесе- ны таблицы справочного и вспомогательно- го характера , программы и т.д. Приложения должны располагаться в порядке появления ссылок в тексте основ- ных разделов . Каждое приложение должно начинаться с нового листа .
6 Правила оформления работы Дипломным работам присваивается обозначение . Оно проставляется на титуль- ном листе пояснительной записки . Обозна- чение состоит из центральной цифровой части , предшествующей и последующей бу- квенных групп . Например ,
ДР 080801.07.000 ПЗ где
ДР – дипломная работа ; первая группа цифр из шести чисел (080801) обозначает шифр специальности ; вторая группа цифр (07) обозначает но- мер задания в соответствии с приказом по институту ;
третья цифровая группа (000) обознача- ет отсутствие чертежей и входящих в них деталей ; ПЗ – пояснительная записка . Все листы пояснительной записки должны быть сброшюрованы в папки фор- мата А4 или потребительского формата , близкого к А4. На папках должны быть эти- кетки размером 60 Х100 мм с указанием аб- бревиатуры университета ( АлтГТУ ), вида документа ( дипломная работа ), кода учеб- ной группы и специальности , автора работы и года окончания выполнения . Пример оформления этикетки :
6.1 Общие требования 6.1.1 Страницы текста пояснительной записки дипломной работы , включенные в пояснительную записку иллюстрации , таб- лицы , распечатки с ЭВМ должны соответст- вовать формату А4 по ГОСТ 9327. Допуска- ется представлять иллюстрации , таблицы и распечатки с ЭВМ на листах формата А3. 6.1.2 Пояснительная записка к диплом- ной работе должна быть распечатана на
принтере на одной стороне листа белой бу- маги через полтора интервала , шрифтом Times New Roman, размер 14, цвет шрифта – черный . Размеры полей : Левое – 20 мм , Правое –10 мм , Верхнее –20 мм , Нижнее - 20 мм . Разрешается использовать компьютер- ные возможности акцентирования внимания на определенных терминах , формулах , тео- ремах , применяя шрифты разной гарнитуры . 6.1.3 Качество напечатанного текста и оформление иллюстраций , таблиц , распеча- ток с ЭВМ должно удовлетворять требова- нию их четкого воспроизведения . При вы- полнении дипломной работы необходимо соблюдать равномерную плотность , чет- кость изображения по всей пояснительной записке . Опечатки , описки , графические неточ- ности , обнаруженные в процессе подготовки работы , допускается исправлять закрашива-
нием белой краской и нанесением на то же место исправленного текста . Повреждения листов текстовых доку- ментов , помарки и следы неполного удале- ния прежнего текста не допускаются . 6.1.4 Сокращение русских слов и слово- сочетаний в работе – по ГОСТ 7.12. 6.1.5 Наименования структурных эле- ментов пояснительной записки дипломной работы «РЕФЕРАТ », « СОДЕРЖАНИЕ », «ВВЕДЕНИЕ », « ОСНОВНАЯ ЧАСТЬ », «ЗАКЛЮЧЕНИЕ », « СПИСОК ИСПОЛЬЗО- ВАННЫХ ИСТОЧНИКОВ », « ПЕРЕЧЕНЬ СОКРАЩЕНИЙ , УСЛОВНЫХ ОБОЗНА- ЧЕНИЙ ...», « ПРИЛОЖЕНИЯ » служат заго- ловками структурных элементов работы . 6.1.6 Заголовки структурных элементов работы следует располагать в середине строки без точки в конце и печатать пропис- ными буквами , не подчеркивая . 6.1.7 Заголовки разделов , подразделов и пунктов следует начинать с абзацного от- ступа и печатать с прописной буквы , не подчеркивая , без точки в конце .
6.1.8 Если заголовок включает несколь- ко предложений , их разделяют точками . Пе- реносы в заголовках не допускаются . 6.1.9 Расстояние между заголовками структурных элементов работы , разделов основной части и текстом должно быть 2 строки . 6.1.10 Пункты и подпункты основной части следует начинать печатать с абзацного отступа , без отрыва от текста . Перед заго- ловком пунктов и подпунктов отступ дол- жен составлять не менее одной строки .
6.2 Нумерация страниц работы 6.2.1 Страницы следует нумеровать арабскими цифрами , соблюдая сквозную нумерацию по всему тексту . Номер страни- цы ставится в центре нижней части листа без точки в конце . 6.2.2 Титульный лист включают в об- щую нумерацию страниц работы . Номер страницы на титульном листе не проставля- ют . 6.2.4 Иллюстрации , таблицы , распечат- ки с ЭВМ , расположенные на отдельных
листах , включают в общую нумерацию страниц пояснительной записки дипломной работы . Иллюстрации , таблицы , распечатки с ЭВМ на листе формата А3 учитывают как одну страницу .
6.3 Нумерация разделов , подразделов , пунктов , подпунктов 6.3.1 Разделы , подразделы , пункты , подпункты следует нумеровать арабскими цифрами и записывать с абзацного отступа . 6.3.2 Разделы дипломной работы долж- ны иметь порядковую нумерацию в преде- лах основной части работы и обозначаться арабскими цифрами без точки , например , 1, 2 и т.д. 6.3.3 Пункты должны иметь порядко- вую нумерацию в пределах каждого раздела или подраздела . Номер пункта включает но- мер раздела и порядковый номер подраздела или пункта , разделенные точкой . 6.3.4 Номер подпункта включает номер раздела , подраздела , пункта и порядковый номер подпункта , разделенные точкой ..
6.3.5 Если раздел или подраздел имеет только один пункт , или пункт имеет один подпункт , то нумеровать пункт ( подпункт ) не следует . 6.3.6 Внутри пунктов ( подпунктов ) мо- гут быть приведены перечисления . Перед каждым перечислением следует ставить дефис или , при необходимости ссылки в тексте записки на одно из перечис- лений , строчную букву ( за исключением ё, з, о, т, ь, й, ы, ъ), после которой ставится точ- ка . Для дальнейшей детализации перечис- лений необходимо использовать арабские цифры , после которых ставится скобка , а за- пись производится с абзацного отступа :
6.4 Иллюстрации 6.4.1 Иллюстрации ( чертежи , графики , схемы , диаграммы , фотоснимки , коды про- грамм ) следует располагать в тексте поясни- тельной записки непосредственно после тек- ста , в котором они упоминаются впервые , или на следующей странице . Иллюстрации могут быть в компьютерном исполнении , в
том числе и цветные . На все иллюстрации должны быть даны ссылки в работе . 6.4.2 Чертежи , графики , диаграммы , схемы , помещаемые в тексте пояснительной записки , должны соответствовать требова- ниям государственных стандартов ЕСКД . 6.4.3 Иллюстрации должны иметь на- звание , которое помещают под иллюстраци- ей . При необходимости под иллюстрацией помещают поясняющие данные ( подрису- ночный текст ). Слово « Рисунок » и наимено- вание помещают после пояснительных дан- ных и располагают следующим образом : Рисунок 1 - Детали прибора . Иллюстрация обозначается словом « Ри- сунок » которое помещают после поясняю- щих данных . 6.4.4 Иллюстрации следует нумеровать арабскими цифрами сквозной нумерацией в пределах всей работы . Допускается нумеровать иллюстрации в пределах раздела . В этом случае номер ил- люстрации состоит из номера раздела и по- рядкового номера иллюстрации , разделен- ных точкой . Например , Рисунок 1.2.
6.4.5 Если в работе только одна иллю- страция , он обозначается « Рисунок 1». Сло- во « рисунок » и его наименование распола- гают посередине строки . 6.4.6 Иллюстрацию следует выполнять на одной странице . Если иллюстрация не умещается на одной странице , можно пере- носить ее на другие страницы , при этом на- звание иллюстрации помещают на первой странице , поясняющие данные - к каждой странице и под ними указывают « Рисунок _, лист _». 6.4.7 При ссылках на иллюстрации сле- дует писать «…в соответствии с рисунком 2» при сквозной нумерации и «…в соответ- ствии с рисунком 1.1» при нумерации в пре- делах раздела . 6.4.8. До иллюстрации и после подри- суночного текста рекомендуется оставлять по одной пустой строке .
6.5 Таблицы 6.5.1 Таблицу , в зависимости от ее раз- мера , следует располагать в пояснительной
записке дипломной работы непосредственно после текста , в котором она упоминается впервые , или на следующей странице , а, при необходимости , в приложении к работе . На- звание таблицы следует помещать над таб- лицей слева , без абзацного отступа , в одну строку с ее номером через тире . На все таблицы должны быть ссылки в работе . При ссылке следует писать слово «таблица » с указанием ее номера . 6.5.2 Таблицы следует нумеровать арабскими цифрами порядковой нумерацией в пределах всей дипломной работы . Допус- кается нумеровать таблицы в пределах раз- дела . В этом случае номер таблицы состоит из номера раздела и порядкового номера таблицы , разделенных точкой . Допускается помещать таблицу вдоль длинной стороны листа дипломной работы . В верхней части длинной стороны листа пишется название таблицы и ее номер . 6.5.3 Если в тексте одна таблица , ее обозначают « Таблица 1». 6.5.4 Название таблицы должно отра- жать ее содержание , быть точным , кратким .
6.5.5 Заголовки граф и строк таблицы следует писать с прописной буквы в единст- венном числе , а подзаголовки граф – со строчной буквы , если они составляют одно предложение с заголовком , или с прописной буквы , если они имеют самостоятельное значение . В конце заголовков и подзаголов- ков точки не ставят . Заголовки и подзаго- ловки граф указывают в единственном чис- ле . 6.5.6 Таблицы слева , справа и снизу , как правило , ограничивают линиями . Разделять заголовки и подзаголовки бо- ковика и граф диагональными линиями не допускается . Горизонтальные и вертикальные линии , разграничивающие строки таблицы , допус- кается не проводить , если их отсутствие не затрудняет пользование таблицей . Заголовки граф , как правило , записы- вают параллельно строкам таблицы . При не- обходимости допускается перпендикулярное расположение заголовков граф . Головка таблицы должна быть отделена линией от остальной части таблицы .
6.5.7. Если строки и графы таблицы выходят за формат страницы , ее делят на части , помещая одну часть под другой или рядом , при этом в каждой части таблицы повторяют ее головку и боковик . При деле- нии таблицы на части допускается ее голов- ку или боковик заменять соответственно номером граф и строк . При этом нумеруют арабскими цифрами графы и ( или ) строки первой части таблицы . Слово « Таблица » указывают один раз слева над первой частью таблицы , над дру- гими пишут слова « Продолжение таблицы » с указанием номера ( обозначения ) таблицы в соответствии с рисунком . Таблица ____________ _________________________
номер название таблицы
Продолжение таблицы ____
6.5. Нумерация граф таблицы арабски- ми цифрами допускается в тех случаях , ко-
гда в тексте имеются ссылки на них , при де- лении таблицы на части , а также при пере- носе части таблицы на следующую станицу . 6.5.9 Оформление таблиц должно соот- ветствовать ГОСТ 1.5 и ГОСТ 2.105. 6.5.10. До и после таблицы рекоменду- ется оставлять по одной пустой строке .
6.6 Перечисления и примечания 6.6.1 Перечисления , при необходимо- сти , могут быть приведены внутри пунктов или подпунктов . Перечисления следует ну- меровать порядковой нумерацией арабскими цифрами со скобкой , например , 1), 2) и т.д., и печатать с абзацного отступа . В пределах одного пункта или подпунк- та не допускается более одной группы пере- числений . 6.6.2 Примечания следует помещать в отчете при необходимости пояснения со- держания текста , таблицы , иллюстрации . Примечания размещают непосредственно после пункта, подпункта , таблицы , иллюст-
рации , к которым они относятся , и печатают с прописной буквы с абзацного отступа . Слово « Примечание » следует печатать с прописной буквы с абзацного отступа и не подчеркивать .
6.7 Формулы и уравнения 6.7.1 Пояснения значений символов и числовых коэффициентов следует приво- дить непосредственно под формулой в той же последовательности , в которой они даны в формуле . Значение каждого символа и чи- слового коэффициента следует давать с но- вой строки . Первую строку пояснения начи- нают со слова « где » без двоеточия . 6.7.2 Уравнения и формулы следует вы- делять из текста в отдельную строку . Выше и ниже каждой формулы или уравнения должно быть оставлено не менее одной сво- бодной строки . Если уравнение не умещает- ся в одну строку , оно должно быть перене- сено после знака равенства (=), умножения (х), деления (:), или других математических знаков .
6.7.3 Формулы в работе следует нуме- ровать порядковой нумерацией в пределах пояснительной записки арабскими цифрами в круглых скобках в крайнем правом поло- жении на строке . Если в работе только одна формула (уравнение ), ее обозначают (1). 6.7.4 Допускается нумерация формул в пределах раздела . В этом случае номер фор- мулы ( уравнения ) состоит из номера раздела и порядкового номера формулы , разделен- ных точкой (3.1). 6.7.5 Формулы , помещаемые в прило- жениях , должны нумероваться отдельной нумерацией арабскими цифрами в пределах каждого приложения с добавлением перед каждой цифрой обозначение приложения , например формула ( В.1). 6.7.6. Ссылки в тексте на порядковые номера формул дают в скобках . 6.7.7. До формулы и после пояснитель- ного текста рекомендуется оставлять по од- ной пустой строке .
6.8 Ссылки
6.8.1 В пояснительной записке допус- каются ссылки на данный документ , стан- дарты , технические условия и другие доку- менты при условии , что они полностью и однозначно определяют соответствующие требования и не вызывают затруднений в пользовании документом . 6.8.2 Ссылаться следует на документ в целом или его разделы и приложения . Ссыл- ки на подразделы , пункты , таблицы и иллю- страции не допускается , за исключением данного документа . 6.8.3. При ссылках на стандарты , тех- нические условия указывают только их обо- значение . 6.8.4 Ссылки на использованные источ- ники следует приводить в квадратных скоб- ках .
6.9 Список использованных источни-
ков
Сведения об источниках даются в соот- ветствии с требованиями ГОСТ 7.0.5
6.10 Перечень сокращений , условных обозначений , символов , единиц и терми- нов Перечень должен располагаться столб- цом . Слева в алфавитном порядке приводят сокращения , условные обозначения , симво- лы , единицы и термины , справа – их деталь- ную расшифровку .
6.11 Приложения 6.11.1 Приложения следует оформлять как продолжение пояснительной записки на ее последующих страницах . 6.11.2 Каждое приложение должно на- чинаться с новой страницы с указанием на- верху посередине страницы слова « ПРИ- ЛОЖЕНИЕ », его обозначение и иметь со- держательный заголовок , который записы- вают симметрично относительно текста с прописной буквы отдельной строкой . Если приложений несколько , их следует обозна- чать заглавными буквами русского алфави- та , начиная с А, за исключением букв Ё, З, Й, О, Ч, Ь, Ы.
6.11.3 Имеющиеся в приложении пунк- ты , подпункты , иллюстрации , таблицы , формулы следует нумеровать в пределах каждого приложения в соответствии с тре- бованиями . 6.11.4 Приложения не должны иметь общую с остальной частью пояснительной записки сквозную нумерацию страниц , ну- мерация для А – А1, А2…, для Б – Б1, Б2,…Если приложение состоит из одного листа , то этот лист не нумеруется . 6.11.5 Если в качестве приложения в работе используется документ , имеющий самостоятельное значение и оформляемый согласно требованиям к документу данного вида , его вкладывают в работу без измене- ний в оригинале .
1
ГОСТ 19.101-77 ЕСПД. Виды программ и программных документов. ГОСТ подразделяет программы на следующие виды: Компонент — программа, рассматриваемая как единое целое, выполняющая законченную функцию и применяемая самостоятельно или в составе комплекса. Комплекс — программа, состоящая из двух или более компонентов, выполняющих взаимосвязанные функции, и применяемая самостоятельно или в составе другого комплекса. Документация, разработанная на программу, может использоваться для реализации и передачи программы на носителях данных, а также для изготовления программного изделия. К числу программных данный ГОСТ относит документы, со- держащие сведения, необходимые для разработки, изготовления, сопровождения и эксплуатации программ. Рассмотрим виды про- граммных документов и их содержание: Спецификация — содержит состав программы и документацию на нее. Ведомость держателей подлинников — содержит перечень предприятий, на которых хранят подлинники программных документов. Текст программы — представляет запись программы с необ- ходимыми комментариями. Описание программы — содержит сведения о логической структуре и функционировании программы Программа и методика испытаний — содержит требования, подлежащие проверке при испытании программы, а также порядок и методы их контроля. Техническое задание — описывает назначение и область при- менения программы, технические, технико-экономические и специальные требования, предъявляемые к программе, необходимые стадии и сроки разработки, виды испытаний. Пояснительная записка — содержит схему алгоритма, общее описание алгоритма и (или) функционирования программы, а также обоснование принятых технических и технико-экономических решений. Эксплуатационные документы — содержат сведения для обес- печения функционирования и эксплуатации программы. Рассмотрим виды и содержание этих документов (табл. 3.2). Таблица 3.2
Вид эксплуатационного документа
Содержание эксплуатационного документа
2
Ведомость эксплуа- тационных документов
Перечень эксплуатационных документов на прог- рамму Формуляр Основные характеристики программы, комплект- ность и сведения об эксплуатации программы
Описание применения Сведения о назначении программы, области применения, применяемых методах, классе решаемых задач, ограничениях для применения, минимальной конфигурации технических средств
Руководство системного программиста
Сведения для проверки, обеспечения функционирования и настройки программы на условия конкретного применения
Руководство программиста
Сведения для эксплуатации программы
Руководство оператора Сведения для обеспечения процедуры общения оператора с вычислительной системой в процессе выполнения программы
Описание языка Описание синтаксиса и семантики языка
Руководство по обслуживанию
Сведения для применения тестовых и диагностических программ при обслуживании технических средств
В зависимости от способа выполнения и характера применения программные документы подразделяются на подлинник, дубликат и копию (ГОСТ 2.102-68), предназначенные для разработки, сопровождения и эксплуатации программы. Допускается объединять отдельные виды эксплуатационных документов (за исключением ведомости эксплуатационных документов и формуляра). Необходимость объединения этих документов указывается в техническом задании. Объединенному документу присваивают наименование и обозначение одного из объединяемых документов. В
3
объединенных документах должны быть приведены сведения, которые необходимо включать в каждый объединяемый документ.
ГОСТ 19.102-77 ЕСПД. Стадии разработки. Устанавливает стадии разработки программ и программной документации для вычислительных машин, комплексов и систем независимо от их назначения и области применения. Стадия разработки Этап работы Содержание работ
Обоснование необходимост и разработки программы
Постановка задачи. Сбор исходных материалов. Выбор и обоснование критериев эффективности и качества разрабатываемой программы. Обоснование необходимости проведения научно-исследовательских работ
Научно- исследователь ские работы
Определение структуры входных и выходных данных. Предварительный выбор методов решения задач. Обоснование целесообразности применения ранее разработанных программ. Определение требований к техническим средствам. Обоснование принципиальной возможности решения поставленной задачи
Разработка и утверждение технического задания
Определение требований к программе. Разработка технико-экономического обоснования разработки программы. Определение стадий, этапов и сроков разработки программы и документации на нее. Выбор языков программирования. Определение необходимости проведения научно-исследовательских работ на последующих стадиях. Согласование и утверждение технического задания
Эскизный проект
Разработка эскизного проекта
Предварительная разработка структуры входных и выходных данных. Уточнение методов решения задачи. Разработка общего описания алгоритма решения задачи. Разработка технико-экономического обоснования
4
Утверждение эскизного проекта
Разработка пояснительной записки. Согласование и утверждение эскизного проекта
Технически й проект
Разработка технического проекта
Уточнение структуры входных и выходных данных. Разработка алгоритма решения задачи. Определение формы представления входных и выходных данных. Определение семантики и синтаксиса языка. Разработка структуры программы. Окончательное определение конфигурации технических средств |
Утверждение технического проекта
Разработка плана мероприятий по разработке и внедрению программ. Разработка пояснительной записки. Согласование и утверждение технического проекта
Рабочий проект
Разработка программы
Программирование и отладка программы
Разработка программной документации
Разработка программных документов в соответствии с требованиями ГОСТ 19.101- 77
Испытания программы
Разработка, согласование и утверждение программы и методики испытаний. Проведение предварительных госу- дарственных, межведомственных, приемо- сдаточных и других видов испытаний. Корректировка программы и программной документации по результатам испытаний
Внедрение Подготовка и передача программы
Подготовка и передача программы и программной документации для сопровождения и (или) изготовления. Оформление и утверждение акта о передаче программы на сопровождение и (или) изготовление. Передача программы в фонд алгоритмов и программ
5
ГОСТ 19.105-77 ЕСПД. Общие требования к программным документам. Данный стандарт устанавливает общие требования к оформлению программных документов для вычислительных машин, комплексов и систем независимо от их назначения и области применения и предусмотренных стандартами Единой системы программной документации (ЕСПД) для любого способа выполнения документов на различных носителях данных. Программный документ может быть представлен на различных типах носителей данных и состоит из следующих условных частей: титульной; информационной; основной. Правила оформления документа и его частей на каждом носителе данных устанавливаются стандартами ЕСПД на правила оформления документов на соответствующих носителях данных. Титульная часть оформляется согласно ГОСТ 19.104-78. Информационная часть должна состоять из аннотации и со- держания. В аннотации приводят сведения о назначении документа и краткое изложение основной части. Содержание включает перечень записей о структурных элементах основной части документа. Состав и структура основной части программного документа ус- танавливаются стандартами ЕСПД на соответствующие документы.
ГОСТ 19.201-77 ЕСПД. Техническое задание. Требования к содержанию и оформлению. Техническое задание (ТЗ) содержит совокупность требований к ПС и может использоваться как критерий проверки и приемки разработанной программы. Поэтому достаточно полно составленное (с учетом возможности внесения дополнительных разделов) и принятое заказчиком и разработчиком ТЗ является одним из основополагающих документов проекта ПС. Техническое задание должно содержать следующие разделы: введение; основания для разработки; назначение разработки; требования к программе или программному изделию; требования к программной документации; технико-экономические показатели;
6
стадии и этапы разработки; порядок контроля и приемки; в техническое задание допускается включать приложения. В зависимости от особенностей программы или программного изделия допускается уточнять содержание разделов, вводить новые разделы или объединять отдельные из них. Содержание разделов ТЗ мы рассмотрим позднее, а пока рассмотрим только требования к программной документации. В данном разделе должны быть указаны предварительный состав программной документации и при необходимости специальные тре-бойания к ней.
1
ГОСТ Р ИСО 9000-2008 Системы менеджмента качества. Основные положения и словарь В стандарте, в Приложении А (Методология, использованная при разработке словаря) в пункте А.3 (Связи между понятиями и их графическое представление) рекомендуются следующие графические построения – три вида связей: родовидовая связь (А.3.2), партитивная связь (А.3.3) и ассоциативная связь (А.3.4). Связи между понятиями основываются на иерархических отношениях между признаками видов таким образом, чтобы наиболее экономное описание понятия образовывалось путем наиме нования его видов и описания признаков, отличающих его от вышестоящих или соподчиненных понятий.
Родовидовая связь
2
Субординатные понятия в рамках иерархии наследуют признаки суперординатного понятия и содержат описания тех признаков, которые отличают их от суперординатных (вышестоящих) и координатных (соподчиненных) понятий, например, связь весны, лета, осени и зимы со временем года. Родовидовые связи изображают графически в виде «веера» или «дерева» без стрелок (рисунок ).
Рисунок 2.1 - Примеры параллельного соединения структур
Партитивная связь Субординатные понятия в рамках одной иерархической системы являются частью суперординатного понятия, например, весна,
3
лето, осень и зима могут быть определены как части года, и недопустимо определять как часть года хорошую погоду (одна из возможных характеристик лета). Партитивные отношения изображаются в виде «грабель» (рисунок *), при этом единичные части изображают одной чертой, а множественные - двумя.
Рисунок 2.2 - Примеры параллельного соединения структур
Ассоциативная связь Ассоциативные связи не столь экономны, как родовидовые и партитивные, но они помогают определить природу взаимоотношений между двумя понятиями в рамках системы понятий, например, причина и следствие, действие и место,
4
действие и результат, инструмент и функция, материал и продукция. Ассоциативные связи изображают в виде одной черты со стрелкой на каждом конце (рисунок *).
Рисунок 2.3 - Примеры параллельного соединения структур
А.4 Графическое представление понятий На рисунке * представлен пример графического изображения понятий, на которых основываются предметные группы раздела 3 стандарта ГОСТ Р ИСО 9000-2008.
5
Рисунок 2.4 - Примеры параллельного соединения структур
6
РД IDEF 0-2000 Методология функ- ционального моделирования IDEF0. Ру- ководящий документ
IDEF – Сокращение от Integration Definition Metodology (Объединение Мето- дологических Понятий). Семейство сов- местно используемых методов для процесса моделирования. IDEF технология используется, начиная с конца 1980-х годов. Department of Defense USA (Министерство обороны США) являет- ся основным пользователем данной техно- логии. Ей, также, пользуются некоторые крупные корпорации в США. IDEF0 (Function Modeling) – данный ме- тод используется для создания функцио- нальной модели, которая является структу- рированным отображением функций произ- водственной системы или среды, а также информации и объектов, связывающих эти функции.
7
IDEF1 (Information Modeling) – данный метод применяется для построения инфор- мационной модели, которая представляет собой структурированную информацию, не- обходимую для поддержки функций произ- водственной системы или среды. IDEF2 (Simulation Model Design) – дан- ный метод позволяет построить динамиче- скую модель меняющегося во времени по- ведения функций, информации и ресурсов производственной системы или среды. Дан- ная модель используется редко. В основном востребована на предприятиях, где необхо- димо описать непрерывную дейтельность на конвейерах или аналогичные функции. IDEF3 (Process Description Capture) – данный метод используется для сбора ин- формации о состоянии моделируемой си- стемы. Это структурный метод, показывающий причинно-следственные связи и события. Он также показывает, как организована работа, и какие пользователи работают с моделиру-
8
емой системой. IDEF3 состоит из двух мето- дов. Process Flow Description (PFD) – описа- ние процессов, с описанием того, как орга- низована работа между различными элемен- тами моделируемой системы. Object State Transition Description (OSTD) – описание пе- реходов состояний объектов, с описанием того, какие существуют промежуточные со- стояния у объектов в моделируемой систе- ме. IDEF4 (Object-Oriented Design) – дан- ный метод объектно-ориентированного пла- нирования был разработан для поддержки объектно-ориентированной идеологии. По- дробнее - Технология UML. IDEF5 (Ontology Description Capture) – данный метод позволяет разрабатывать, изучать и поддерживать онтологию модели- руемой системы. Термин «онтология» включает в себя каталог терминов области знаний; правила, объясняющие, как термины могут комбинироваться, создавая при этом корректные ситуации в области знаний и со-
9
гласованные выводы, используемые в моде- лируемой системе. IDEF6 (Design Rational Capture Method) - данный метод позволяет использовать ра- циональный опыт проектирования. IDEF7 ( Information System Auditing) - данный метод описывает проведение мето- дологии аудита информационной системы. IDEF8 (User Interface Modeling) – дан- ный метод позволяет разрабатывать необхо- димые модели Графического Интерфейса Пользователя (Human-System Interaction Design). Метод предназначена для проекти- рования взаимодействия человека и техни- ческой системы. IDEF9 (Business Constraint Discovery) - данная модель предназначена для анализа имеющихся условий и ограничений (в том числе физических, юридических или любых других) и их влияния на принимаемые ре- шения в процессе реинжиниринга. IDEF10 - Implementation Architecture Modeling Моделирование архитектуры
10
выполнения. Этот метод определѐн как вос- требованный, однако так и не был полно- стью разработан; IDEF11 - Information Artifact Modeling Этот метод определѐн как востребованный, однако так и не был полностью разработан; IDEF12 - Organization Modeling Органи- зационное моделирование. Этот метод опре- делѐн как востребованный, однако так и не был полностью разработан; IDEF13 - Three Schema Mapping Design Трѐхсхемное проектирование преобразова- ния данных. Этот метод определѐн как вос- требованный, однако так и не был полно- стью разработан; IDEF14 (Network Design) - данный ме- тод позволяет моделировать вычислитель- ные сети. Модель предназначена для пред- ставления и анализа данных при проектиро- вании вычислительных сетей на графиче- ском языке с описанием конфигураций, оче- редей, сетевых компонентов, требований к надежности.
11
РД IDEF 0 – 2000 Методология функционального моделирования IDEF0. Руководящий документ • IDEF0 используется для создания функциональной модели, отображающей структуру и функции системы, а также потоки информации и матери альных объектов, связывающие эти функции. • IDEF1 применяется для построения информационной модели, отображающей структуру и содержание информационных потоков, необходимых для поддержки функций системы; • IDEF2 позволяет построить динамическую модель меняющихся во времени поведения функций, информации и ресурсов системы. • IDEF3 - методология моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами
12
обработки информации и объектов, являющихся частью этих процессов..
К настоящему времени наибольшее распространение и применение имеют методологии IDEF0 и IDEF1 (IDEF1X), получившие в США статус федеральных стандартов.
Синтаксические правила.
Рисунок 2.5 - Примеры параллельного соединения структур
13
Блоки Размеры блоков должны быть достаточными для того, чтобы включить имя блока. Блоки должны быть прямоугольными, с прямыми углами. Блоки должны быть нарисованы сплошными линиями.
Рисунок 2.6 - Примеры параллельного соединения структур
Имя блока должно быть активным глаголом или глагольным оборотом. Каждая сторона функционального блока должна
14
иметь стандартное отношение блок/стрелки: а) входные стрелки должны связываться с левой стороной блока; б) управляющие стрелки должны связываться с верхней стороной блока; в) выходные стрелки должны связываться с правой стороной блока; г) стрелки механизма (кроме стрелок вызова) должны указывать вверх и подключаться к нижней стороне блока. д) стрелки вызова механизма должны указывать вниз, подключаться к нижней стороне блока, и помечаться ссылкой на вызываемый блок.
15
Рисунок 2.7 - Примеры параллельного соединения структур
Сегменты стрелок, за исключением стрелок вызова, должны помечаться существительным или оборотом существительного, если только единственная метка стрелки несомненно не относится к стрелке в целом. Чтобы связать стрелку с меткой, следует использовать "тильду" ( ). В метках стрелок не должны использоваться следующие термины: функция, вход, управление, выход, механизм, вызов.
Контекстная диаграмма верхнего уровня. Каждая модель должна иметь контекстную диаграмму верхнего уровня, на которой объект моделирования представлен единственным блоком с граничными стрелками. Эта диаграмма называется A-0
16
(А минус нуль). Стрелки на этой диаграмме отображают связи объекта моделирования с окружающей средой. Поскольку единственный блок представляет весь объект, его имя – общее для всего проекта. Это же справедливо и для всех стрелок диаграммы,
Рисунок 2.8 - Примеры параллельного соединения структур
17
Дочерняя диаграмма . Единственная функция, представленная на контекстной диаграмме верхнего уровня, может быть разложена на основные подфункции посредством создания дочерней диаграммы. В свою очередь, каждая из этих подфункций может быть разложена на составные части посредством создания дочерней диаграммы следующего, более низкого уровня, на которой некоторые или все функции также могут быть разложены на составные части. Каждая дочерняя диаграмма содержит дочерние блоки и стрелки, обеспечивающие дополни тельную детализацию родительского блока.
18
19
Рисунок 2.9 - Примеры параллельного соединения структур
Код формируется так:
Рисунок 2.10 - Примеры параллельного соединения структур
Нотация VAD