Введение Для решения простейших задач программирования необходимо знать средства и возможности конкретного языка программирования. По мере усложнения задач знание свойств языка, оставаясь необходимым, уже не является фактором, определяющим успех проектирования программы. На первый план выдвигаются знание и умение конструировать логику вычислительного процесса в целом, а не отдельных его шагов. Определяющими здесь становятся вопросы методологии и технологии программирования.
I. Исследование состояния рынка программного обеспечения Динамика развития компьютерного рынка в России впечатляет Это - самый динамичный сектор отечественной экономики, который ближе других находится к мировому уровню. Примерно так довольно единодушно оценивают состояние нашей компьютерной действительности самые различные эксперты, и местные и зарубежные. В целом с такими характеристиками можно, конечно, согласиться.
Но все же, если говорить на эту тему более конкретно, то хотелось бы уточнить - а что собственно понимается под тезисом развитие компьютерного рынка ? Например, в некотором упрощенном варианте он делится на две части технические средства и ПО. Что касается критериев оценки состояния рынка техники, то здесь все более менее понятно налицо рост объемов продаж, количества установленных компьютеров, процессоры 486 и Pentium сменяют устаревшие 286 и 386 и т.д. Хотя при ближайшем рассмотрении становится ясно, что особенно
обольщаться наши успеха в области железа не следует. Так, по оценкам фирмы Dataquest осень 1995 г. в Германии должно было продано в 1995 г. почти 4 млн. ПК, а России около одного миллиона. Это хотя и позволит выйти нам на 6-е место в Европе по объемам продаж, но догнать, например, Нидерланды, все же не удастся. При этом имеется явная тенденция к замедлению темпов роста объемов продаж
Год 1999 Продажи ПК тыс. шт. 2230 Прирост 15 Динамика развития российского рынка ПК данные фирмы Dataquest Кстати, по данным фирмы IDC рост продаж ПК в США составил в 1995 г. 22 . И так уже много лет. Что же касается программного обеспечения, то здесь
ясности относительно критериев оценок его состояния гораздо меньше. Что считать главным число или рост установленного ПО или продаваемого? Число рост отечественных пользователей ПО или разработчиков? Короче говоря, что мы понимаем под рынком программного обеспечения? Сегодня основные оценки связаны с изучением изменения структуры
ПО. К примеру, число пользователей Windows в 1995 составило 60 40 в 1994 г а DOS - 17 30 . При этом, как правило, речь идет только о пользователях а не покупателях и только относительных величинах. Такие оценки конечно же нужны, хотя только их явно недостаточно. Но об этом позднее, а сейчас хотелось бы взглянуть на то, как этих оценки обычно получаются. Немного о теории статистических исследований В последнее время на различных компьютерных конференциях,
на страницах печати все чаще появляются некоторые конкретные количественные оценки отечественного компьютерного рынка. Они представляют безусловный интерес, но все же хотелось бы обратить внимание на проблему достоверности подобных данных. Когда представитель некоторой фирмы говорит о количественных показателях своей фирмы, то это не вызывает никаких сомнений. Но если говорится, например, о реализуемых продуктах по Москве в целом, то появляется вполне резонный вопрос о том, каким образом была получена эти результаты.
К сожалению, почему-то такие вопросы считаются не очень приличными как в старом анекдоте, джентльмены верят на слово . Но все дело в том, что порою складывается впечатление, что подобные исследования ведутся на довольно-таки любительском уровне. Одним из популярных методов сбора информации является различного рода анкетирование - читателей журналов, посетителей выставок и пр. В связи с этим следует заметить, что к результатам подобных опросов нужно относиться весьма осторожно.
Прежде всего, полезно вспомнить, что основополагающий принцип любых исследований заключается в следующем объемы и методы исследований определяются их конечной целью задачей . Более конкретно это можно сформулировать таким образом - прежде чем собирать какую-то информацию, следует довольно четко представлять, для чего это делается. Опыт показывает, что абстрактный сбор информации часто бывает просто ненужным.
Второй вопрос является более конкретным насколько представительной является полученная выборка, т.е. насколько состав людей, ответивших на вопросы анкет, соответствуют реальной ситуации. Например, насколько отражают реальный круг пользователей читатели данного журнала или посетители некоторой компьютерной выставки? Не менее важным методическим вопросом является принцип отбора участников анкетирования, т.е. насколько представительной является выборка даже среди, например, читателей журнала.
Здесь надо четко представлять, что по результатам заполненных читателями анкет можно получить лишь портрет человека, который решил отправить анкету . При этом вполне возможно, это будет портрет читателя, которому просто нечем другим заняться. В начале прошлого года один популярный московский компьютерный журнал проводил подобное анкетирование читателей и я имел возможность познакомиться с их первыми откликами.
Я обратил внимание, что абсолютное большинство заполнивших анкеты - школьники, хотя у меня есть веские причины думать, что их процент среди читателей существенно ниже. Разумеется, это дело журнала решать, как ему общаться с читателями, но все же вряд ли имеет смысл планировать свою деятельность на не очень представительной информации. А если эта выборка достоверна, то знает ли о ней рекламодатель
ORACLE 7, который закупил целую страницу журнала? В связи с этим могу привести пример того, как на разные темы и по нескольку раз в год проводит подобные исследования американский журнал Visual Basic Programmer s Journal я постоянно слежу за этим изданием, являясь координатором Ассоциации Пользователей MS Basic . Редакция сама делает случайную, представительную выборку из своей базы данных о читателях и рассылает им анкеты, при этом обеспечивая самыми различными способами, чтобы
получить ответ на каждый свой запрос. Разумеется, эта процедура сложнее и дороже, но качество результатов стоит того - это уже хороший коммерческий товар. Что же такое рынок ПО? Обычный постановка вопросов, связанных с анализом рынка программных средств, звучит примерно так Чем Вы пользуетесь сегодня и с чем собираетесь работать завтра На такие вопросы, конечно, можно получить полезную информацию, но все же она изначально не является
достаточной для анализа рынка. Прежде всего, давайте вспомним, что понятие рынок непосредственно связано с понятием товар , а товаром, как известно является не просто какая-то вещь, а то, что предназначено для продажи. Соответственно, видны и три группы действующих участников рынка производители разработчики , продавцы поставщики и покупатели пользователи . И с этой точки зрения рынок ПО должен однозначно отождествляться с рынком легального распространения программ.
При этом совершенно очевидно, что в условиях нашей российской действительности этот рынок затрагивает только относительно небольшую часть общей массы программных средств, имеющихся у пользователей компьютеров. Тем не менее, принимая во внимание то, что даже среди нелегалов существуют какие-то минимальные товарно-денежные отношения, я предлагаю в последующем подразумевать под рынком ПО совокупность всех программных продуктов и их пользователей, отдельно выделяя в нем его легальную
составляющую. Здесь мне хотелось бы отметить некорректную постановку некоторых вопросов анкетирования на последней выставке WinExpo 95. В разделе программные продукты вопросы строились такими парами что Вы используете? что Вы собираетесь покупать? Совершенно очевидно, что использовать и покупать в России являются разными понятиями. Поэтому более логичной и точной была бы такая постановка что Вы используете в т.ч. купили ? что Вы собираетесь использовать в т.ч. покупать ?
Смысл этих уточнений мне представляется важным потому, что, говоря об исследовании рынка ПО, по-видимому, гораздо более актуальным является не то, как изменилось соотношение использования операционных систем, а то, какова динамика изменения объема всего рынка программных средств и как в нем меняется общая доля легальной части. Конечно, можно анализировать изменение предпочтений в области СУБД, но кому нужны подобные исследования, если, предположить, что общий объем их продаж равен нулю
и нет тенденций к его увеличению? Причем, мне представляется, что в первую очередь нас должно интересовать развитие именно легального рынка, который оказывает достаточно большое может быть даже решающее влияние на развитие всего рынка ПО в целом. Почему? Да, потому, что без настоящих рыночных отношений у нас будет социализм застой . Это мы уже проходили. Как определить объем и структуру легального рынка, теоретически понятно - нужно собрать сведения о продажах у поставщиков
ПО хотя, конечно, это непросто сделать . Но как определить размеры всего рынка? И самое главное нужно ли это делать? Ответ на последний вопрос вроде бы утвердительный Конечно, нужно. Ведь именно это определяет потенциал развития объемов продаж программ . Однако здесь не все так просто. В беседах с руководителями различных фирм-поставщиков ПО за последние годы мне неоднократно приходилось слышать такую мысль.
Мы ориентируемся в своей работе на тех, кто в состоянии покупать программы, а нищие пользователи нас не интересуют. Разумеется, бизнесменам виднее, как вести свои дела, но хотел бы обратить внимание читателей на такой момент. Четыре года назад рынок продовольственных товаров тоже начинался с коммерческой торговли для солидных клиентов , но по мере его развития продавцы гоняются даже за бедными пенсионерами. А поставщики ПО до сих пор считают сотни тысяч средних школ и тысячи высших учебных заведений
России мертвой зоной, предпочитая работать только с несколькими сотнями банков и верхушкой государственного аппарата. Кстати, обратите внимание первым в мире покупателем Windows 95 был простой парень из Новой Зеландии, а не Bank of America. Этот косвенный факт вполне годится для выдвижения такой гипотезы российский рынок ПО пробуксовывает и, вполне возможно, даже отстает от общего развития рынка страны.
Как развивается легальный рынок ПО? Определенный прогресс здесь, конечно, налицо. Об этом можно судить по такому факту, что продажа программного обеспечения стала прибыльным делом и есть целый ряд крупных фирм, для которых это стало основным или даже единственным занятием. Еще два-три года такого не было - отделы продажи программного обеспечения были на правах бедных родственников у компьютерных фирм, которые жили за счет продажи оборудования.
Но сегодняшним фактом является то, основная направленность абсолютного большинства наших поставщиков ПО - работа с крупными заказчиками банки, правительство, Дума и пр Точной информации о состоянии рынка ПО в России явно недостаточно. Наиболее достоверными сведениями на этот счет является официальная информация российского АО Microsoft о результатах финансовой деятельности за 1994-95 финансовый год.
Из этого отчета видно, что доходы АО Microsoft возросли вдвое по сравнению с предыдущим периодом. Однако принять эту цифру за большое достижений трудно, учитывая, что в 1993 году российское отделение Microsoft начинало практически с нуля. Анализируя состояние российского легального рынка ПО, следует обратить внимание, что доходы Microsoft в России составили 0,2 от общих показателей корпорации, в то время как в
США и Канаде - 35 , Европе - 25 . Эти данные не учитывают поставки ПО изготовителями оборудования OEM , составляющие 28 , с учетом которых разница была бы еще более значительной. Однако и эти цифры не дают полного представления о ситуации в России по сравнению с цивилизованным компьютерным рынком. К сожалению, у меня нет конкретных данных об объемах продаж поставщиками
ПО, но утверждение о том, что степень монополизации Microsoft в России существенно выше, чем у себя в США, мне кажется, довольно очевидным. И дело даже не в том, что в России другое соотношение среди фирм-гигантов. Гораздо более важным представляется то, что на отечественном рынке практически полностью отсутствуют относительно мелкие производители программных средств, которые во всем мире заполняют практически все
поры потребительского спроса. При этом их суммарные объемы продаж занимают весьма значительную долю. Например, в последнем обзоре дополнительных программных продуктов для Visual Basic, который ежегодно проводит американский журнал Visual Basic Programmer s Journal, приведен каталог из более 1000 подобных средств, выпуском которых занимается несколько сотен фирм. По сведениям того же журнала, каждый пользователь
VB применяет в своей работе с среднем 5-10 таких дополнительных средств, общую стоимость которых можно оценить не менее 1000 долл. Таким образом, принимая во внимание, что стоимость самого VB составляет в среднем менее 200 долл. с учетом скидок Upgrade , становится видно, что доля Microsoft на рынке собственного продукта составляет около 20 . В целом, возвращаясь к вопросу о динамике развития легального рынка
ПО, можно констатировать, что цифры о двухкратном увеличении продаж АО Microsoft в России не очень впечатляют по нескольким причинам. Во-первых, при старте с нулевой отметки относительные изменения мало о чем говорят. Во-вторых, вполне возможно, что темпы роста продаж у других поставщиков ПО еще ниже. По оценкам Российской компьютерной ассоциации, которые были приведены на семинаре
Intel в Москве 29 июня сего года, темпы роста продаж легального ПО в России резко падают и к концу года могут сократиться до нуля! Рынок ПО в целом Можно, безусловно, признать, что компьютерный рынок России действительно динамично развивается, внедряясь в самые различные сферы нашей жизни. При этом можно довольно уверенно утверждать, что расширение компьютерного парка происходит в значительной
степени за счет именно тех слоев нашего общества, которые отечественными поставщиками ПО были признаны неперспективными и находятся вне поля их интересов. Как бы то ни было, время бурной структурной перестройки страны завершается, и вряд ли можно ожидать продолжения значительного роста числа частных предприятий, банков, АО и пр. Скорее, мы уже сейчас видим сокращение их количества.
С другой стороны, можно говорить о стабилизации, оживлении и даже некотором подъеме в системе образования, научно-исследовательских организациях, промышленности. Еще один динамично развивающийся сектор пользователей ПК - домашние компьютеры. По довольно единодушным оценкам это будет наиболее мощным направлением расширения рынка ПК в ближайшие годы и к 2000 году по оценкам, например,
Intel может выйти на уровень использования компьютеров в бизнесе. В России этот процесс развивается тоже достаточно динамично. На примере своего круга друзей и знакомых наверное, к нему с некоторой натяжкой больше подходит термин средний класс - бывшая научно-техническая интеллигенция я могу сказать, что компьютеры уже сейчас имеются в большинстве семей, причем основная часть имеет процессоры 486 и
Pentium, купленные за последний год. При этом я могу уверенно сказать, что легальных пользователей ПО среди них практически нет. Структура рынка разработки программных средств Для анализа рынка ПО представляется целесообразным посмотреть на его структуру с точки зрения самих программных средств. В этом плане можно воспользоваться классификацией программных продуктов и соответственно их разработчиков , которую привел Генеральный директор
АО Microsfot Р.Клаф в своем выступлении на конференции DevCon 95 июнь, г. Обнинск внутрифирменные программные средства продукты вертикальных специальных решений коммерческие продукты широкого применения. В основу этой классификации положен простой принцип - тираж распространения, широта охвата круга пользователей от единичного исполнения до сотен тысяч и более для России . Внутрифирменное ПО разрабатываются, как правило, по специальным заказам собственными или сторонними
программистами. Наверное, именно к нему относится часто используемый в последнее время термин заказное ПО . ПО вертикальных решений является коммерческим и предназначено для использования ограниченным кругом пользователей в определенных предметных областях издательские системы, научные пакеты и пр Довольно принципиальным отличием между программными продуктами двух последних групп является способ их распространения ПО широкого применения изначально ориентировано на использование разветвленной сети
поставщиков и, в этом плане, его можно охарактеризовать как коробочное ПО. Специальное ПО распространяется, прежде всего, самими разработчиками для России это особенно характерно , и только самые его лучшие образцы - через третьих продавцов. Легальный рынок - правовые аспекты Три-четыре года назад одной из любимых тем нашей компьютерной прессы было обсуждение Закона об охране авторских прав на программы .
Тогда этот Закон обсуждался в таком ключе, что казалось, что как только он будет принят, в России автоматически установится цивилизованный рынок ПО. Однако закон уже три года как вошел в силу, а принципиальных изменений на рынке не наблюдается. Мне кажется, что в этом году мы были свидетелями мощнейшего всплеска активности нелегального рынка программных продуктов в связи с появлением новых носителей информации - компакт-дисков
CD-ROM . Если раньше у нас имело место именно копирование как правило бесплатное программ, то теперь можно определенно говорить о возникновении именно черного рынка , оборот которого, несмотря на бросовые цены на программы, вполне возможно, не уступает легальному . С учетом этого, исследования российского ПО скорее следует проводить не на ежегодных выставках WinExpo, SofTool и COMTEK, а на ежедневных рынках в
Митино и Царицыно. Конечно, можно говорить о дикости российского рынка и загадочной русской душе , которая не хочет жить по законам компьютерной цивилизации. Можно говорить о невнимании к этой проблеме со стороны государственных, в том числе, правовых органов, хотя их в какой-то степени понять можно - им сейчас не до этого. Но нужно говорить также об отсутствии деятельных шагов в этом направлении заинтересованной стороны
- разработчиков и поставщиков ПО, у которых дальше сетований по поводу компьютерных пиратов дело пока не идет. Это было, в частности, хорошо заметно по довольно вялой дискуссии на семинаре Проблемы нелегального копирования ассоциации BSA Business Software Alliance , который как-то незаметно прошел на конференции WinExpo 95. Кстати, созданная года четыре назад российская
Ассоциация поставщиков ПО, первоочередная декларируемая цель которой была борьба за цивилизованный рынок, просто незаметно прекратила свое существование. Честно говоря, я ожидал услышать там какой-то анализ ситуации на легально-нелегальном рынке, а также хотя бы концептуальную программу действий по ее изменению. Однако основная часть времени ушла на обсуждение проблемы почему милиция не борется с пиратами . Но ведь понятно, данная проблема милицейскими методами не решается, более того нужно бороться в первую
очередь не с нелегальным копированием, а с нелегальным использованием ПО. И для этого требуются нетривиальные действия со стороны всех заинтересованных лиц. Например, в беседах с руководителями АО Microsoft я еще три года назад предлагал подумать о том, чтобы провести компанию по легализации пользователей QuickBasic в России. Но этого не было сделано, в результате чего огромная часть российских пользователей оказалась
просто вне закона, так как его уже тогда в принципе нельзя было купить. Я хотел бы обратить внимание на то, что сегодня этот язык является одним из основных средств обучения программированию как в средней, так и высшей школе. И сейчас этим людям будет уже сложнее объяснить, почему теперь Visual Basic нужно покупать, а не просто переписывать.
Но и обвинять в бездеятельности российское отделение Microsoft тоже не очень корректно. Ведь давайте не забывать, что они - лишь представители разработчика правообладателя и их возможности по принятию каких-то нетривиальных решений весьма ограничены. В связи с этим мне хотелось бы обратить внимание то, что одной из основных причин нашей пробуксовки на пути к легальному рынку является слабость именно российских производителей программных средств, которые
должны бы были возглавить это движение. А заокеанские фирмы-разработчики по-серьезному нашими проблемами заниматься вряд ли будут. Какое нам дело до проблем легального рынка? Действительно, какое нам, пользователям, дело до того, как развивается легальный рынок ПО в России? Пусть об этом болит голова у разработчиков и поставщиков ПО. Более того, эта ситуация вроде бы даже очень удобна для пользователей - за 15-20 долл. в
Царицыно можно закупить все мыслимое на сегодняшний день программное обеспечение. Однако подобное благополучие весьма иллюзорно. Прежде всего, специалисты, занимающиеся разработкой программного обеспечения, составляют достаточно большое число участников рынка ПО. По оценкам РосАПО сегодня в России занимаются производством программных продуктов 200-250 тыс. специалистов. С учетом разработчиков внутрифирменного ПО эта цифра, наверное, может увеличится вдвое.
И хотя программисты, безусловно, составляют меньшинство среди компьютерных пользователей, но в силу своего положения профессионалов они оказывают очень серьезное влияние на состояние рынка ПО. Так вот, отсутствие легального рынка, продолжение, а возможно и расширение объемов пиратского копирования в значительной степени подрывает экономическую базу деятельности российских программистов. Разумеется, сокращение числа программистов 3-4 года назад было вполне естественным с учетом как структурной
перестройки нашей экономики ее спадом, в том числе , так и переходом от разработок типа сделай сам на каждом предприятии к использованию готовых решений. Но продолжение этого процесса об этом говорят, в частности, результаты опроса посетителей выставок, есть и ряд других косвенных признаков на фоне расширения компьютерного рынка выглядит уже весьма тревожно. Самый сильный удар наносится по сегменту разработчиков коммерческих продуктов широкого назначения.
Более того, сейчас можно говорить о том, что российских производителей таких продуктов практически нет. Это очень хорошо видно на примере текстового процессора Лексикон. Конечно, можно просто констатировать то, что Лексикон сдает свои позиции и сейчас лидером стал Word for Windows, объясняя переходом пользователей в Windows.
Но можно взглянуть на этот же факт и с другой стороны. В частных беседах с представителями Микроинформ фирма-разработчик Лексикона я неоднократно слышал, что продажа этого продукта практически не приносит никакой прибыли, и фирма продолжает его поддержку скорее из соображений престижа. И это при том, что по числу установленных копий Лексикон наверное уступает только
MS-DOS и NC. На этом фоне становится совершенно очевидной заметная вялость фирмы по выпуску и продвижению новых версий Лексикона, в том числе для Windows. В этих условиях лидерство Word обеспечено независимо от его потребительских качеств, так как его мощная поддержка и развитие обеспечивается огромным доходом от его продажи во всем мире но не России . Таким образом, оптимизм некоторых публикаций в компьютерной прессе об успехах отечественных
разработчиков представляется слишком преувеличенным. Это, в частности, подтверждается и крайне небольшим списком приводимых примеров успешных коммерческих разработок, которые, как правило, представляют специальные решения. Результатом всего этого совершенно естественно выглядят попытки некоторых программистских фирм выйти на международный рынок, минуя российский, хотя в плане разработки программ это задача на порядок более
сложная. В непростом положении находятся и разработчики сектора специализированных программных продуктов. Эти продукты в меньшей степени подвержены риску пиратского размножения как правило, пользователь заинтересован в технической поддержке авторов . Но довольно часто встречается другая проблема пользователь не может купить нужный продукт по той простой причине, что забыл заложить в смету своих работ стоимость программных продуктов или не может объяснить своему руководству, зачем нужно покупать программу, когда ее можно
просто скопировать. Что же касается разработчиков внутрифирменного ПО, то их конкурентоспособность еще больше снижается по сравнению с бесплатными готовыми решениями. К тому же они оказываются лишенными технической поддержки со стороны авторов средств разработок, не говоря уже об отсутствии документации. Так что конечным пользователям не приходится особенно рассчитывать на активность отечественных разработчиков. Однако и на импорт зарубежных программных продуктов надежд
довольно мало. Я уже пытался обратить внимание читателей в своих предыдущих статьях, что зарубежный ассортимент программных продуктов у нас России представлен крайне слабо. Например, из тысячи продуктов сектора Visual Basic у нас доступен только один - сам Visual Basic фирмы Microsoft. Но без наличия разнообразных дополнительных средств выполнять серьезные, конкурентоспособные или просто специфические разработки довольно сложно.
Аналогичную ситуацию я наблюдаю и в другой близкой для меня области - программное обеспечение для научных исследований. Причины этой ситуации совершенно ясны мелкими производителям ПО а именно они закрывают огромных рынок специальных решений очень сложно выйти на российский рынок по экономическим причинам - хлопот очень много и заниматься поставкой отдельных коробок никто не хочет заниматься. Но сейчас часто встречается и другая ситуация, когда разработчик из
США просто отказывается продавать свой продукт, узнав, что его покупатель живет в России доход от отдельной проданной коробки небольшой, а потери могут быть весьма значительные, так как пиратское тиражирование просто закроет для него перспективы дальнейшего сотрудничества. Таким образом, получается, что дешевизна программных продуктов на отечественном рынке выходит боком для всех нас кто-то теряет работу, кто-то переплачивает за заказные программы, вместо того, чтобы купить
готовые, кто-то не может решить свои прикладные задачи и пр. И причина всего заключается в том, что в основе развития отечественного программного рынка пока еще нет его самого главного стимула развития - нормальных рыночных отношений. II. Технология разработки программного продукта 1. Юридические основы создания и использования программного изделия 0.
Эта лицензия применима к любой программе или другой работе, содержащей уведомление о владельце copyright и о том, что она может распространяться в соответсвии с требованиями Генеральной Общедоступной Лицензии. Программа , употребляемый далее термин, относится к любой программе или работе, а также работе основанной на Программе . Это означает, что Программа или производная работа находятся под охраной copyright то есть работа,
содержит Программу или ее часть либо дословно, либо с модификациями и или переводами на другой язык. Далее перевод включается без дополнительных оговорок в термин модификация . Далее под обращением вы будем понимать владельца лицензии. Другая деятельность, отличная от копирования, распространения и модификации, не подпадает под действие этой Лицензии она за ее пределами ее влияния. Собственно эксплуатация
Программы ничем не ограничивается и выходные данные, выдаваемые Программой попадают под Лицензию, только если их можно отнести к работе, основанной на Программе независимо от того, что данные получены в результате выполнения Программы . Либо действительно зависит от того, что делает Программа. 1. Вы можете копировать и распространять точные копии исходных текстов
Программы, как вы их получили, на любом носителе, снабженном заметным и подобающим образом представленным уведомлением о copyright и уведомлением об отсутствии гарантии сохраняйте без изменений записи, относящиеся к этой Лицензии и отсутствию гарантии и передавайте другим вместе с копией Программы копию этой Лицензии. Вы можете получать плату за саму физическую процедуру передачи копии и вы можете за плату под свою ответственность предложить от своего имени гарантии.
2. Вы можете модифицировать свою копию Программы или ее части, таким образом реализуя работы, основанные на Программе, а далее копировать и распределять эти модификации и другие работы в терминах Раздела 1, обеспечив выполнение всех условий a. Модифицированные файлы вы должны снабдить на видном месте в начале уведомлением, что вы изменили файлы, и датой изменений. b. Вы должны снабдить любую работу, которую вы распространяете или публикуете, как целиком, так и частями,
или полученную на основании Программы или ее части, лицензией, позволяющей бесплатно передавать третьим лицам на основании Лицензии. c. Если модифицированная программа должна читать в интерактивном режиме команды в процессе выполнения, вы должны обеспечить, чтобы в начале работы она автоматически выдавала объявления, включающие соответствующий copyright и уведомление об отсутствии гарантии либо, наоборот, сообщение, что вы предоставляете гарантию и что пользователь может заниматься дальнейшим распространением
программы при соблюдении этих условий, а также информацию пользователю, где можно увидеть копию этой лицензии. Исключение Если Программа сама по себе интерактивная, но в нормальном режиме не выдает такие сообщения, ваша работа, базирующаяся на Программе не обязана выдавать эти объявления . Эти требования применимы к работам, связанным с модификацией в целом. Если выделенная часть этой работы не является производной от
Программы, и может обоснованно рассматриваться как независимая и отдельная работа, тогда эта Лицензия и ее составляющие не применимы к этим частям, когда они распространяются как независимые работы. Но когда вы распространяете эти части внутри целого, что можно определить, как работу на основе Программы, распространение целого должно попадать под требования этой Лицензии, чьи ограничения для получателей лицензии будут распространяться на целое, и таким образом
все части, вне зависимости от того, кто что написал. Таким образом, это не следует воспринимать как попытку заявить свои права или оспаривать ваши права, на работу написанную целиком вами, а намерение реализовать право управления распространением производных или коллективных работ , основанных на Программе. В дополнение, простое объединение другой работы, не основанной на Программе с Программой или работой, основанной на
Программе на одном томе хранения или средстве распространения не переносит действие Лицензии на эту другую работу. 3. Вы можете копировать и распространять Программу или работу, основанную на программе из Раздела 2 в объектных кодах или выполняемой форме с учетом требований Разделов 1 и 2, при условии, что вы также выполните одно из следующего a. Сопроводите ее полными машинно-читаемыми исходными текстами, которые должны распространяться с учетом
требований Разделов 1 и 2, на средстве кастомизации, используемом для обмена программами или b. Сопроводите ее письменным предложением, действительным не менее, чем в течение трех лет, продать любой третьей стороне по стоимости, не большей, чем стоимость физического копирования дистрибутива, полную машинно-читаемую копию соответствующего исходного кода, который можно распространять с учетом ограничений Разделов 1 и 2, на средствах кастомизации, используемых для обмена программами или c.
Сопроводить ее информацией, которую вы получили в качестве предложения по распространению соответствующего исходного кода. Эта альтернатива допускается только для некоммерческого распространения, и только если вы получили программу в качестве предложения в объектных кодах или выполняемой форме, в соответствии с Подразделом b, приведенным выше . Исходный код предпочтителен для работ по модификации. Полный исходный код подразумевает весь исходный код для содержащихся модулей, плюс все файлы определения
интерфейса, плюс сценарии управления компиляцией и инсталляцией. Однако, в качестве специфического исключения, распространяемый исходный код не обязан содержать то, что обычно распространяется в исходных текстах или бинарном виде с основными программными компонентами компилятором, ядром и т.п. операционной системы, на которой программа выполняется, за исключением случая, когда сама компонента сопровождает выполняемые файлы.
Если распространение выполняемых или объектных кодов реализуется предоставлением доступа для копирования из указанного места, тогда предоставление эквивалентного доступа для копирования исходных исходного кода из того же места считается распространением исходного кода, даже если третьи стороны не принуждаются копировать исходный код вместе с объектным кодом. 4. Вы не должны копировать, модифицировать, дополнительно лицензировать или распространять
Программу иначе, чем под данной Лицензией. Иначе любая попытка копировать, модифицировать, дополнительно лицензировать или распространять Программу будет нарушением и автоматически аннулирует ваши права, защищаемые данной Лицензией. Однако третьих сторон, получившие копии или права по этой Лицензии, они не аннулируются, пока они их не нарушают. 5. Вы можете не следовать этой Лицензии, коль скоро вы ее не подписывали.
Однако, ничто другое не дает вам права модифицировать или распространять Программу или производные из нее работы. Эти действия запрещены законом, если вы не принимаете требования Лицензии. Поэтому, занимаясь модификацией или распространением Программы или любой работы, основанной на Программе вы должны продемонстрировать вашу приверженность этой Лицензии, в связи с этими работами, и всем требованиями и условиям по копированию, распространению
или модификации Программы или работ, основанных на Программе. 6. Каждый раз, когда вы передаете Программу или работу, основанную на Программе , получатель автоматически получает лицензию от первого владельца лицензии на копирование, распространение или модификацию Программы с учетом требований и условий. Вы не имеете права накладывать дополнительные ограничения на использование
Программы теми, кому вы ее передаете. Вы не отвечаете по претензиям, предъявляемым третьими сторонами к этой Лицензии. 7. Если по решению суда или по заявлению о нарушении патента или по другой причине не ограниченной патентными спорами на вас накладываются требования решением суда, действующим договором или чем-то иным , которые противоречат условиям Лицензии, это не является основанием для нарушения вами условий Лицензии. Если вы не можете одновременно выполнять условия
Лицензии и выполнять другие обязательства, то вы вообще не имеете права распространять Программу. Например, если требования патента не разрешают бесприбыльное распространение Программы всеми теми, кто прямо или опосредованно получил от вас копии, тогда единственный вариант, позволяющий не нарушать как те, так и другие требования, заключается в отказе от распространения Программы вообще. Если какая-то часть этого раздела не применима к конкретной ситуации или невыполнима
при некоторых конкретных обстоятельствах, то предполагается, что часть раздела или весь раздел применимы в других обстоятельствах. Целью этого раздела не является попытка подтолкнуть вас к нарушению каких-либо патентных прав или прав собственности, или оспаривать справедливость таких прав. Этот раздел имеет единственную цель - защиту целостности системы свободно распространяемых программ, которая реализуется практикой общедоступных лицензий.
Многие люди внесли большой вклад в обширный набор свободно распространяемых программ, полагаясь на эту систему. Это право автора дарителя решать, желает ли он она распространять программы через какие-то другие системы и мы не может навязывать выбор. Целью данного раздела было уточнение того, что является следствием последующего содержания Лицензии. 8. Если распространение и или использование Программы ограничено в некоторых странах либо патентами, либо запатентованными интерфейсами, исходный
владелец патента, который поместил Программу по данную Лицензию, может добавить явно указанную географию распространения, исключив соответствующие страны, так что распространение будет разрешено среди стран, не попавших в список исключенных. В этом случае данная Лицензия включает ограничения, как неотъемлемую часть своего текста. 9. The Free Software Foundation FSF может публиковать и или изменять время от времени
Генеральную Общедоступную Лицензию. Эти новые версии будут аналогичны по духу данной версии, но могут отличаться в деталях, связанных с вновь возникшими проблемами. Каждая версия имеет уникальный номер. Если Программа указывает номер версии данной Лицензии, которая включает и любую более раннюю версию , вы можете следовать требованиям либо данной версии, либо любой более ранней версией, опубликованной
Free Software Foundation. Если Программа не указывает номер версии Лицензии, вы можете выбрать любую когда-либо опубликованную Free Software Foundation версию. 10. Если вы хотите вставить части Программы в другие свободно распространяемые программы, чьи условия распространения отличаются, напишите автору и спросите его разрешения. Для программ, защищенных copyright
Free Software Foundation, напишите в Free Software Foundation мы иногда делаем для этого исключения. Наше решение следует двум целям сохранения статуса свободно распространяемых программ для всех производных из этих программ, и вообще, поощрение распространения программ. ОТКАЗ В ГАРАНТИИ 11. ПОСКОЛЬКУ ПРОГРАММА ИМЕЕТ ЛИЦЕНЗИЮ БЕСПЛАТНО РАСПРОСТРАНЯЕМОЙ ПРОГРАММЫ,
НА ПРОГРАММУ ОТСУТСТВУЕТ ГАРАНТИЯ В ПРЕДЕЛАХ ДОПУСКАЕМЫХ ЗАКОНОМ . ЗА ИСКЛЮЧЕНИЕМ ТЕХ СЛУЧАЕВ, КОГДА ПИСЬМЕННО УКАЗАНО ОБРАТНОЕ, ВЛАДЕЛЬЦЫ COPYRIGHT И ИЛИ ДРУГИЕ ПОСТАВЛЮТ ПРОГРАММУ КАК ЕСТЬ БЕЗ КАКОЙ БЫ ТО НИ БЫЛО ГАРАНТИИ, ЯВНОЙ ИЛИ ПОДРАЗУМЕВАЕМОЙ, ВКЛЮЧАЯ, НО НЕ
ОГРАНИЧИВАЯ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ, НЕОБХОДИМЫЕ ПРИ ТОРГОВЛЕ И ОБЯЗАТЕЛЬНЫЕ ДЛЯ ДРУГИХ КОНКРЕТНЫХ ЦЕЛЕЙ. ВЫ БЕРЕТЕ НА СЕБЯ ВЕСЬ РИСК ЗА КАЧЕСТВО И РЕЗУЛЬТАТЫ РАБОТЫ ПРОГРММЫ. ЕСЛИ ПРОГРАММА ОКАЖЕТСЯ НЕИСПРАВНОЙ, ВЫ НЕСЕТЕ ВСЕ РАСХОДЫ ПО НЕОБХОДИМОМУ ОБСЛУЖИВАНИЮ,
РЕМОНТУ ИЛИ КОРРЕКТИРОВКЕ. 12. НИ В КАКИХ СЛУЧАЯХ, КРОМЕ СЛЕДУЮЩИХ ИЗ ЗАКОНОВ ПО ИСПОЛЬЗОВАНИЮ ИЛИ СОГЛАСИЯ В ПИСЬМЕННОЙ ФОРМЕ, НЕ БУДЕТ НИ ОДИН ВЛАДЕЛЕЦ COPYRIGHT ИЛИ ДРУГОЕ ЛИЦО, КОТОРОЕ МОГЛО МОДИФИЦИРОВАТЬ ПРОГРАММУ И ИЛИ ДАЛЕЕ РАСПРОСТРАНЯТЬ ЕЕ В СООТВЕТСТВИИ С УСТАНОВЛЕННЫМИ
РАЗРЕШЕНИЯМИ, НЕ БУДЕТ НЕСТИ ОТВЕТСТВЕННОСТЬ ЗА НАНЕСЕННЫЙ ПРОГРАММОЙ УЩЕРБ, ВКЛЮЧАЯ ЛЮБОЙ УЩЕРБ ОБЩЕГО ХАРАКТЕРА, СПЕЦИАЛЬНЫЙ, СЛУЧАЙНЫЙ ИЛИ ЯВЛЯЮЩИЙСЯ СЛЕДСТВИЕМ ПОВРЕЖДЕНИЯ, ВЫЯВЛЕННОГО ПРИ ИСПОЛЬЗОВАНИИ ПРОГРАММЫ ИЛИ НЕВОЗМОЖНОСТИ ИСПОЛЬЗОВАТЬ ПРОГРАММУ ВКЛЮЧАЯ, НО НЕ ОГРАНИЧИВАЯСЬ,
ПОТЕРЮ ДАННЫХ ИЛИ ИХ НЕПРАВИЛЬНУЮ ПЕРЕДАЧУ ИЛИ ПОТЕРИ, КОТОРЫЕ ПОНЕСЛИ ВЫ ИЛИ ТРЕТЬЯ СТОРОНА, ИЛИ НЕСПОСОБНОСТЬ ПРОГРАММЫ ВЗАИМОДЕЙСТВОВАТЬ С ДРУГИМИ ПРОГРАММАМИ , ДАЖЕ ЕСЛИ У ВЛАДЕЛЬЦЕВ ИЛИ ТРЕТЬЕЙ СТОРОНЫ КОНСУЛЬТИРОВАЛИСЬ ПО ПОВОДУ ВОЗМОЖНОСТИ ТАКОГО УЩЕРБА. 2. Структура жизненного цикла программы
Проекты по созданию программных продуктов можно разделить по объему работы и сложности можно разделить на большие и малые. Характеристики малых проектов программа создается одним или несколькими программистами за несколько дней или недель один человек в состоянии охватить все детали проекта детали проекта обсуждаются с пользователем и частично записываются на бумаге. Характеристики больших проектов программа создается большой группой программистов и пользователей за
несколько недель, месяцев или лет нет и не может быть человека, который знает все детали проекта. Работа над большими программными продуктами не сравнимо сложнее. Например, рассмотрим ситуацию Вы написали программу, которая содержит 1000 строк, Вы смогли выполнить эту работу за неделю, сколько времени у Вас займет написание программы на туже тему в объеме 2000 строк?
На первый взгляд кажется, что достаточно 2 недель, но на самом деле, вероятно, Вам потребуется около 4 недель. Между объемом работы и временем существует квадратичная зависимость. Рисунок Чтобы реализовать большой проект необходимо придерживаться четкой последовательности действий, иметь стратегический план. Таким стратегическим планом является жизненный цикл программного продукта. Структура жизненного цикла программного продукта Жизненный цикл программного продукта может изменяться
от проекта к проекту. Как правило, он состоит из следующих этапов Сбор и анализ требований заказчика Уточнение функциональных характеристик Техническое проектирование Кодирование Тестирование и отладка Сопровождение программного продукта Временная диаграмма Рисунок По статистическим данным кодирование составляет только 1 6 от первых пяти этапов.
Преимущества применения жизненного цикла разработки программного продукта Разногласия и отсутствие связи между членами команды разработчиков и между разработчиками и конечными пользователями быстро обнаруживаются и устраняются Hовые люди безболезненно подключаются к проекту на любой стадии разработки. Конечное приложение базируется на фундаментальном анализе задачи, что позволяет свести к минимуму затраты
на дальнейшую доработку, модификацию и сопровождение продукта. В процессе разработки создается мощный пакет документации, позволяющий в дальнейшем упростить неизбежное сопровождение и дополнения программного продукта. Один раз хорошо отработанный цикл разработки приложения позволяет сэкономить много времени при реализации последующих проектов. Разберем каждый этап. Этап 1. Сбор и анализ требований заказчика
С чего начинается работа над проектом? Обычно к Вам обращается пользователь с предложением написать программу. Ваша задача - получить у пользователя всю необходимую информацию и оговорить условия создания программного продукта. В разработке программного продукта принимает участие группа разработчиков и пользователей. Кого из пользователей желательно подключить к работе над программой? Директор Зам. директора Руководители среднего звена начальники отделов
Рядовые сотрудники Директор, зам. директора полезны при работе над программным продуктом тем, что именно они принимают окончательное решение о его разработке и оплате. Руководители предприятия знают задачу в целом и определяют основные направления развития предприятия. Руководители среднего звена хорошо знают работу своего подразделения. Рядовые сотрудники в деталях знают свою часть задачи, но, обычно, не имеют системного виденья задачи.
При работе над проектом желательно поддерживать связь и с рядовыми сотрудниками, и с руководителями. Для Вас имеет большое значение, кто будет работать с Вашей программой, каков его профессиональный уровень и уровень компьютерной грамотности, его предпочтения в смысле программных продуктов. Вы должны знать, что является более приоритетным для конечного пользователя. Одни системы требуют максимального внимания к внешнему оформлению и особенностям эксплуатации, другие
- максимальной скорости и удобства ввода данных при максимально упрощенном внешнем виде системы. скорость часто снижается при использовании средств ограничения доступа и защиты информации. Удостоверьтесь, что пользователи понимают значение скорости безопасности внешней привлекательности простоты использования размера данных и способа их организации А какими качествами должен обладать разработчик, который собирает пожелания и требования пользователя?
Это должен быть хороший специалист, который умеет общаться с людьми и объяснить технические термины простым языком. На этапе сбор и анализ требований заказчика Вы должны выяснить функции, которые должен выполнять программный продукт. Какие данные являются входными, выходными, промежуточными. основную цель его создания. Действительно очень важно найти истинную цель приложения, чтобы иметь возможность определить границы
проекта. аппаратное и программное обеспечение клиента. Важно оценить окружение, в котором будет работать Ваша программа. Клиенты тратят большие средства на приобретение аппаратных средств еще до того, как обращаются к Вам. Вы должны выяснить все детали о сетевых аппаратных и программных ресурсах типах компьютеров операционной системе типах принтеров, мониторов, дисководов других периферийных устройствах безопасность
и управление. Прежде чем начать разработку, конечный пользователь должен определить необходимость обеспечения безопасности системы и данных. Включение системы обеспечения безопасности должно рассматриваться на самой ранней стадии проектирования. сотрудничество с пользователям. Перед началом проектирования системы необходимо выяснить, на что pасчитывает конечный пользователь. Hеобходимо обратить внимание на следующие аспекты инсталляция обучение пользователей поддержка программного
продукта помощь в эксплуатации Методы получения информации Для получения информации чаще всего используется личная беседа, в ходе которой разработчик записывает пожелания пользователя. Можно собрать и опросить сразу нескольких пользователей, это особенно целесообразно, если пользователи решают сходные задачи. Метод изучения путем анализа материала. Разработчик может попросить для изучения документы, с которым работают пользователи на рабочем местах.
Обычно применяется для выяснения вопросов, на которые невозможно получить ответы от исполнителей. Например, максимальные и минимальные значения данных, качество заполнения документов. Для выяснения отдельных вопросов, может применяться специальный документ- опросный лист. В опросный лист заносятся наиболее интересные для пользователя особенности. Наиболее полную информацию можно получить приличном наблюдении.
Данный метод применяется, если обследование по существу, выполнено, необходимо уточнить лишь некоторые детали без отрыва исполнителей от их профессиональной деятельности. Можно исследовать документооборот, технологию создания документов. Метод личного участия в работе. Применяется редко, обычно, когда по важным вопросам получены противоречивые сведения или когда другим путем нельзя получить ответ.
Например, при изучении техники заполнения документов, при разработки инструкции по заполнению документов. Метод аналогий. Достаточно изучить работы одного исполнителя, имея в виду, что другие выполняют аналогичные операции. Например, работа бухгалтера-расчетчика Сбор и анализ требований заказчика является очень важным этапом. Все недочеты на этом этапе в дальнейшем проявятся и могут привести к конфликтам с пользователем, к затягиванию сроков работы над проектом и большему объему работы 3.
Виды программ, программной и эксплуатационной документации по ЕСПД. Программа, как правило, разрабатывается не для того, кто является ее автором. Программу необходимо разрабатывать так, чтобы было понятно, как ее запускать, какой метод решения задачи в ней заложен, каковы требования к вводу выводу и т.д. Например, если в программной документации не указана размерность вводимых данных, то пользователь будет
в большом затруднении при работе с такой программой. При разработке программной документации нужно придерживаться государственных стандартов, объединенных в Единую систему программной документации ЕСПД . Согласно ГОСТ 19.10177 Виды программ и программных документов программы делятся на компоненты и комплексы. Компонент это программа, рассматриваемая как единое целое, выполняющая законченную функцию и применяемая
самостоятельно или в составе комплекса. Комплекс это программа, состоящая из двух или более компонентов и или комплексов, выполняющих взаимосвязанные функции, и применяемая самостоятельно или в составе другого комплекса. Указанный стандарт определяет в качестве программных документы, содержащие сведения, необходимые для разработки, изготовления, сопровождения и эксплуатации программы. Все документы делятся на две группы программные таблица1 и эксплуатационные таблица 2 .
Таблица 1Вид программного документа Содержание программного документа Спецификация Состав программы и документации на нее Ведомость держателей подлинников Перечень предприятий, на которых хранят подлинники программных документов Текст программы Запись программы с необходимыми комментариями Описание программы Сведения о логической структуре и функционировании программы
Программа и методика испытаний Требования, подлежащие проверке при испытании программы, а также порядок и методы их контроля Техническое задание Назначение и область применения программы, технические, технико-экономические и специальные требования, предъявляемые к программе, необходимые стадии и сроки разработки, виды испытаний Пояснительная записка Схема алгоритма, общее описание алгоритма и или функционирования программы, а также обоснование принятых технических и технико-экономических решений
Таблица 2Вид документа Содержание документа Ведомость эксплуатационных документов Перечень эксплуатационных документов на программу Формуляр Основные характеристики программы, комплектность и сведения об эксплуатации программы Описание применения Сведения о назначении программы, области применения, применяемых методах, классе решаемых задач, ограничениях на применение, минимальной конфигурации технических средств
Руководство системного программиста Сведения для проверки, обеспечения функционирования и настройки программы на условия конкретного применения Руководство программиста Сведения для эксплуатации программы Руководство оператора Сведения для обеспечения процедуры общения оператора с вычислительной системой в процессе выполнения программы Описание языка Описание синтаксиса и семантики языка
Руководство по техническому обслуживанию Сведения для применения тестовых и диагностических программ при обслуживании технических средств Строгой регламентации перечня документов для каждой программы ГОСТ 19.101-77 не устанавливает, так как сложность программы и условия ее эксплуатации могут варьироваться в таких широких пределах, что невозможно точно указать, какая именно документация должна быть разработана в каждом конкретном случае. По этой причине ГОСТ 19.10177 допускает объединение отдельных видов эксплуатационных
документов за исключением ведомости эксплуатационных документов и формуляра . Рекомендуемый перечень документов, разрабатываемых в процессе выполнения курсовой работы, должен включать Техническое задание Не следует путать техническое задание и задание бланк на курсовую работу, получаемое студентом от руководителя. На основании последнего студент разрабатывает техническое задание в соответствии с требованиями ГОСТ 19.101-77 см. табл.1 и ГОСТ 19.102-77.
Описание программы. Текст программы. Программу и методику испытаний тестирования . Описание применения. Поскольку вся документация, разрабатываемая в процессе выполнения курсовой работы, должна отвечать требованиям ЕСПД, ниже приводится необходимая часть содержания стандартов. Общие сведения о ЕСПДСогласно ГОСТ 19.001-93 Единая система программной документации. Общие требования , ЕСПД это комплекс государственных стандартов, устанавливающих взаимоувязанные правила
разработки, оформления и обращения программ и программной документации. Регламентация указанных процессов обеспечивает возможность унификации программных изделий для взаимного обмена программами и применения ранее разработанных программ в новых разработках снижения трудоемкости и повышения эффективности разработки, сопровождения, изготовления и эксплуатации программных изделий автоматизации изготовления и хранения программной документации.
Каждый документ должен иметь титульный лист и лист утверждения. Правила их заполнения регламентируются ГОСТ 19.10478 Единая система программной документации. Основные надписи . На титульный лист и лист утверждения выносятся следующие надписи наименование министерства наименование документа обозначение документа сведения о носителе данных, на котором представлен подлинник общее количество
листов утверждения объем документа сведения о разработчике подпись нормоконтролера отметка об учете и хранении сведения об изменениях. Лист утверждения оформляется на каждый программный документ на листах формата А4 ГОСТ 2.301-68 независимо от вида документа, который может быть выполнен на любом носителе данных. Обозначение листа утверждения состоит из обозначения документа, к которому он относится, и через дефис - шифра листа утверждения. Лист утверждения не входит в общее количество листов документа.
Лист утверждения хранится на предприятии-держателе подлинника документа. Копии листа утверждения высылают заказчику и головному предприятию. Программные документы подразделяются в зависимости от способа выполнения и характера применения на подлинники, дубликаты и копии ГОСТ 2.102-68 , предназначенные для разработки, сопровождения и эксплуатации программы. Титульный лист заполняют по форме и правилам, установленным для листа утверждения.
Правила оформления последующих листов программных документов регламентируется ГОСТ 19.105-78 Единая система программной документации. Общие требования к программной документации . Согласно этому стандарту программный документ состоит из следующих условных частей титульной информационной основной регистрации изменений. Титульная часть состоит из листа утверждения и титульного листа.
Информационная часть включает аннотацию и содержание перечень разделов, подразделов с указанием номеров страниц . В аннотации приводятся сведения о назначении документа и краткое изложение его основной части. Состав и структура основной части программного документа устанавливается другими стандартами ЕСПД с частью из них мы познакомимся ниже . Программные документы выполняют на листах формата А4 ГОСТ 2.30668 . Материалы программного документа располагают в последовательности титульная часть
лист утверждения титульный лист первый лист документа информационная часть аннотация лист содержания основная часть текст документа с рисунками, таблицами и т. п. приложения перечень терминов перечень сокращений перечень рисунков перечень таблиц предметный указатель перечень ссылочных документов перечень символов и числовых коэффициентов часть регистрации изменений лист регистрации изменений. Составляющие основной части, начиная от приложения и далее, выполняются при необходимости.
Рассматриваемый ГОСТ 19.106-78 устанавливает правила оформления, размещения в документе и нумерации текста, рисунков, таблиц и формул из-за ограниченности объема методических указаний они здесь не приводятся . Иллюстрированный материал, таблицы или текст вспомогательного характера допускается оформить в виде приложений. Приложения оформляют как продолжение данного документа или выпускают в виде отдельного документа. Каждое приложение должно начинаться с новой страницы с указанием в правом верхнем углу слова
ПРИЛОЖЕНИЕ и иметь тематический заголовок, записываемый симметрично тексту прописными буквами. На приложения должны быть даны ссылки в основном документе. Все приложения должны быть перечислены в листе Содержание . 4. Перечень, содержание и приемы выполнения работ на этапе разработки программного изделия. А Постановка задачи Постановка задачи должна содержать следующие разделы наименование и область применения
основание для разработки назначение разработки технические требования к программе или программному изделию технико-экономические показатели стадии и этапы разработки порядок контроля и приемки приложения. В зависимости от особенностей программы или программного изделия допускается уточнять содержание разделов, вводить новые разделы или объединять отдельные из них. Б Выбор и обоснование метода решения Описывается метод, с помощью которого решена данная задача, а
так же предпосылки для выбора именно этого метода. В Разработка алгоритма Использование схем В технической документации часто встречаются различные схемы алгоритмов, программ, данных и систем и т.д. Схемы состоят из имеющих заданное значение символов, краткого пояснительного текста и соединительных линий. Схемы могут использоваться на различных уровнях детализации, причем число уровней зависит от размера и сложности задачи обработки данных.
Уровень детализации должен быть таким, чтобы различные части и взаимосвязь между ними были понятны в целом. ГОСТ 19.701-90 определяет символы предназначенные для использования в схемах 1. ДАННЫХ 2. ПРОГРАММ 3. РАБОТЫ СИСТЕМЫ 4. ВЗАИМОДЕЙСТВИЯ ПРОГРАММ 5. РЕСУРСОВ СИСТЕМЫ В схемах используются основные символы, в тех случаях, когда тип процесса или носителя данных неизвестен или когда нет необходимости в описании фактического носителя специфический
символ, используется в тех случаях, когда точно известен тип процесса или носителя информации Основные символы Рисунок Специфические символы Рисунок Символы процесса Рисунок Пример 1. Процессы С, D, E не могут начаться до тех пор, пока не завершится процесс А. Аналогично процесс F должен ожидать завершения процессов B, C, D, однако процесс С может начаться или и закончиться прежде, чем соответственно начнется и или
завершиться процесс D. Рисунок Рисунок Рисунок Рисунок Специальные символы Рисунок Пример 2. Программа анализирует ряд чисел и подсчитывает их количество, определяет максимальное и минимальное значение. Числа вводятся пользователем, их количество заранее не известно, число ноль - признак конца ввода. Т.о. ввод происходит до тех пор, пока пользователь не введет число ноль. Схема программы. Рисунок Текст программы. include iostream.h void main int
N, min 32767, max - 32768 , c 0 cout nВведите число cout n 0-признак окончания ввода cin N while N! 0 c if N min min N if N max max N cout nВведите число cin N cout n Чисел прочитано t c cout n наименьшее t min cout n наибольшее t max Пример 3. Схема данных Магазин на диване . По почте приходят заказы на различные товары. Оператор проверяет правильность их заполнения код товара, количество, адресные данные и затем вводит
в программу. Программным путем формируется список заказов на каждый товар, письмо клиенту которое будет вложено посылку и почтовая наклейка с адресом клиента. Рисунок Г Составление программы на одном из алгоритмических языков Описывается язык программирования на котором будет решена данная задача и преимущества этого языка перед другими. Д Отладка и тестирование программы Краткие теоретические сведения
Тестирование процесс выполнения программы с целью обнаружения допущенных в ней ошибок. Тестирование не является иллюстрацией работоспособности программы. Такой подход в значительной мере обеспечивает успех тестирования, обусловленный психологическим настроем обнаружить ошибки, а не продемонстрировать их отсутствие. Тестирование должно быть организовано по следующим принципам согласно
Майерсу 1. каждый тест должен включать описание ожидаемых результатов работы программы, чтобы можно было быстро выяснить наличие или отсутствие ошибок в ней 2. желательно, чтобы кроме автора тестирование проводили и другие люди. Т.к. обнаружение недостатков в своей деятельности противоречит человеческой психологии, восприятие человека со стороны ближе к восприятию пользователя, чем психология автора, однако отладка программы эффективнее всего выполняется именно автором программы 3. по тем же соображениям организация
- разработчик программного обеспечения - не должна единолично его тестировать должны существовать организации, специализирующиеся на тестировании программных средств 4. результаты каждого теста должны быть документированы и детально изучены, чтобы не пропустить малозаметную на поверхностный взгляд ошибку в программе 5. тесты для неправильных непредусмотренных данных должны подбираться так же тщательно, как и для правильных предусмотренных входных данных 6. при анализе результатов каждого теста необходимо проверять, не делает
ли программа того, что она не должна делать 7. следует сохранять использованные тесты для повышения эффективности повторного тестирования программы после ее модификации или установки у заказчика 8. тестирования не должно планироваться исходя из предположения, что в программе не будут обнаружены ошибки в частности, следует выделять для тестирования достаточные временные и материальные ресурсы 9. следует учитывать так называемый принцип скопления ошибок вероятность наличия не обнаруженных ошибок в некоторой части
программы прямо пропорциональна числу ошибок, уже обнаруженных в этой части 10. следует всегда помнить, что тестирование - творческий процесс, а не относиться к нему как к рутинному занятию. По степени охвата проекта различают изолированное тестирование промежуточное тестирование комплексное тестирование Изолированное тестирование Изолированное тестирование тестирование отдельных частей проекта. Применяется, если компоненты проекта образуют дерево и между ними нет циклических зависимостей.
Тестирование можно разбить по слоям, сначала оттестировав самый низкий слой компонент, зависящий только от внешних библиотек и не зависящий от каких-либо других компонент программы. Потом на слой выше - зависящих от внешних библиотек и от компонент самого низкого слоя. Так можно вести тестирование до тех пор, пока компонента имеет достаточно узкий диапазон применения, и заранее легко можно рассчитать, какой результат должен быть после работы этой компоненты.
Таким тестированием удается реально выловить большинство мелких ошибок, серьезно нарушающих работу программы, также можно определить эффективность интерфейса и алгоритмов, реализованных в программе. Для выполнения тестирования можно использовать специальные программы тестеры. Второй вариант вместо неготовых компонент можно использовать так называемые программы-заглушки и программы-драйверы. Заглушка не несет серьезной функциональности, а как правила просто выдает сообщение на экран.
Программа драйвер передает тестируемому компоненту необходимые тестовые данные и отображает результаты. Другая проблема, которую необходимо решать при нисходящем тестировании форма представления тестов в программе, так как, как правило, главный модуль получает входные данные не непосредственно, а через специальные модули ввода, которые при тестировании в начале заменяются заглушками. Для передачи в главный модуль разных тестов нужно или иметь несколько разных заглушек, или записать
эти тесты в файл во внешней памяти и с помощью заглушки считывать их. Модули, содержащие операции ввода-вывода, а так же критические модули т.е. наиболее важные для программы в целом должны тестироваться как можно раньше. Промежуточное тестирование Когда несколько компонент связаны между собой данными сложного формата, то изолированное тестирование будет провести достаточно тяжело. Тогда тест строится для некоторого множество компонент и проверяется
результат работы всего комплекса. Комплексное тестирование Комплексное тестирование проводится уже почти полностью написанной программы. Цель такого тестирование - проверить выполняет ли программа требуемые от нее функции. Обычно на этой стадии определяются дефекты алгоритмов, сложные ошибки, возникшие в результате неверного использования компонент или взаимодействия между ними, и недостатки функциональных возможностей.
Если не проводить предварительно изолированное и промежуточное тестирование, то на этой стадии будет слишком много ошибок, чтобы их можно было легко исправить, поэтому придется долго выпускать тестовые версии. Комплексное тестирование, выполненное разработчиками, называется альфа-тестированием. В результате исправления ошибок появляется так называемая альфа-версия программы. Обычно альфа-версию поставляют ограниченному кругу конечных пользователей для более жесткого тестирования.
Хорошо известно, что пользователи иногда используют программное обеспечение не совсем для тех целей, для которых оно предназначалось. Поэтомy могут обнаружиться неожиданные ошибки в тех местах пpогpаммы, которые разработчики считают абсолютно правильными. Комплексное тестирование программного продукта пользователями называется бетта-тестированием. В результате исправления найденных ошибок появляется бетта-версия программы.
Как правило, бетта-версия проходит еще одно комплексное тестирование у разработчиков приемочный тест . Чтобы удостовериться, что все ошибки исправлены и не возникло никаких новых проблем. Приемочный тест особенно важен, если программное обеспечение будет разослано большому количеству пользователей. Стратегии тестирования Практика работы позволяет выделить две стратегии тестирования 1. Черного ящика функциональное тестирование 2. Белого ящика структурное тестирование
Стратегия черного ящика - тестирование с управлением по данным по входу - выходу . Целью тестирования является выяснение обстоятельств, при которых поведение программы не соответствует спецификации. При таком подходе обнаружение ошибок может быть достигнуто путем исчерпывающего входного тестирования, т.о. в качестве тестовых наборов используются все возможные наборы входных. Простейшие примеры показывают, что это практически невозможно.
Поэтому чтобы не перебирать все возможные значения применяются методы 1. Эквивалентного разбиения, 2. Анализа граничных значений, 3. Гипотез ошибок. Метод эквивалентного разбиения состоит в разбиении входной области программы на конечное число классов эквивалентности, при котором каждый тест данного класса эквивалентен в смысле обнаружения ошибок любому другому тесту этого класса.
Разработка тестов методом эквивалентного разбиения происходит в два этапа выделение классов эквивалентности и построение тестов. Классы эквивалентности выделяются на основе анализа входных условий спецификации программы, при этом разделяют два типа классов эквивалентности правильные соответствуют правильным входным данным и неправильные представляющие ошибочные входные данные . Хотя выделение классов является эвристическим процессом, существует ряд правил, позволяющих его формализировать.
Например, если входное условие описывает ситуацию должно быть , то определяется один правильный класс и по крайней мере один неправильный. Пример. Программа рассчитывает функцию Рисунок Область допустимых входных значений по определению логарифма Рисунок Область допустимых значений данных сокращенно ОДЗ х 2.3, 18 Рисунок Выделим 3 класса эквивалентности на основе
ОДЗ Рисунок Круглые скобки означают, что точка не входит в отрезок, квадратные скобки - точка входит в отрезок это минус бесконечность это плюс бесконечность. Из каждого класса берется одно значение. Вы может выбрать любое на Ваше усмотрение. Так для класса 1 можно было, с таким же успехом, взять значение 0 или -0.5. Графа ожидаемый результат просчитывается вручную или на калькуляторе.
Графа результат заполняется при тестировании набранной программы. В дальнейшем сравнение ожидаемого результата и результата работы программы позволит Вам сделать вывод, о правильной или неправильной работе Вашей программы. Метод граничных значений - это дополненный анализом граничных значений входных условий метод эквивалентного разбиения. Для каждого класса эквивалентности выбирается значение, которое входит
в класс изнутри класса , значения находящиеся на границе и значения с незначительным отклонением от границы рядом с границей . Рисунок Когда мы рассматриваем два смежных класса, граничное значение должно войти только в один из этих класса. В нашем примере границы между классами - это значения x 2.3333 входит в класс 1 и x 18 входит в класс 3 Пример. Предыдущий пример дополнится новыми значениями. Рисунок В класс 1 добавилось граничное значение х 2.3 и значение расположенное рядом с границей x 2.32
В класс 2 добавились два значения расположенные рядом с границей x 2.34 и x 17.99 В класс 3 добавилось граничное значение х 18 и значение расположенное рядом с границей x 18.01 Применение метода гипотез ошибок основано на интуитивном предположении об ошибках. Составляется список возможных ошибок и исключительных ситуаций, которые могут появиться в программах данного класса. Достаточное научное обоснование метода возможно на основе широкого анализа предметной
области и классификации ошибок и исключительных ситуаций. Пример. Пусть необходимо рассчитать функцию f x log Гипотеза для расчета функции f x необходимо рассчитывать При больших значения x может произойти переполнение и, следовательно, может возникнуть ошибка. В качестве теста рассчитаем f 3.3 1038 1.9844908 Стратегия белого ящика - это тестирование с управляемое
логикой программы. Стратегия основана на анализе внутренней структуры программы. Стратегия белого ящика включает проверку покрытие операторов, решений, условий, покрытие решений условий, комбинированное покрытие. Покрытие операторов. Набор текстов должен быть таким, чтобы каждый оператор программы выполнился хотя бы один раз. Составим программу для расчета функции f x include iostream.h include math.h define LG a,b log a log b float f float x float y1, y2 y1
LG 36-2 x, x x y2 LG 3 x-7, x return y1 y2 void main float x,y cout nВведите х t cin x if x 2 1.0 3 x 18 y f x cout ny y else cout nНе корректные входные данные Тесты по методу покрытия операторов Рисунок Достаточно взять два значения х. При 2.3 х 18 например, х 3 , выполняться все операторы, кроме cout nНе корректные входные данные Для его проверки достаточно взять х 18 или x 2.3333, например, x 0.
Метод покрытия решений. При покрытии всех решений каждый маршрут выполнения программы должен быть реализован хотя бы один раз. Пример. Рисунок Обозначим ветви условного оператора буквами a, b, c, d. В данном случае существует 4 маршрут выполнения программы ac, ad, bc, bd. Набор тестов должен быть таким, чтобы каждый маршрут был реализован хотя бы один раз. Пример. По координатам точки х, y определить принадлежит ли точка осям координат.
Фрагмент программы if x 0 cout nТочка на оси ОY if y 0 cout nТочка на оси ОX Рисунок Тесты по методу покрытия решений Рисунок Значения х и у могут быть произвольными. Единственное требование, чтобы они позволяли проверить нужный маршрут. Покрытие условий. Для каждого условия необходимо проверить его выполнение и невыполнение хотя бы один раз. Пример. По координатам точки х, y определить в какой координатной четверти лежит точка.
if x 0 y 0 cout n первая четверть if x 0 y 0 cout n вторая четверть if x 0 y 0 cout n третья четверть if x 0 y 0 cout n четвертая четверть Рисунок Рисунок Плюс кодирует выполнение условия, минус - не выполнение. Возьмем такие точки, чтобы условия x 0 и y 0 выполнялись кодируются , например x 2 и y 4, при этом условия x 0 и y 0 будут не выполнены кодируются Теперь, наоборот, возьмем такие точки, чтобы условия
x 0 и y 0 не выполнялись кодируются например x -3 и y -3, при этом условия x 0 и y 0 будут выполнены кодируются . Вы видите, что метод покрытия условий не всегда позволяет проверить все ветви и операторы программы. В данном случае проверены только первый и третий операторы. Поэтому тест по методу покрытия условий обычно используется совместно с другими тестами. Например, дополняется требованием, чтобы каждый оператор программы был выполнен хотя бы один раз.
Пример. Рисунок Добавим тесты для проверки второго и четвертого операторов. Пример 2. Для фрагмента программы do k 50 j k Q необходимо проверять условия k 50, k 50, j k Q, j k Q. Несмотря на очевидные преимущества, критерий покрытия условий не всегда удовлетворяет критерию покрытия решений. Пример, пусть тестируется фрагмент программы if a b блок операторов 1 Для покрытия условий требуется два теста а - истинно , b -ложно и a -ложно, b истинно .
Однако эти тесты не проверяют выполнение блока оператор 1. Улучшенный тест - покрытие решений условий. Он требует, чтобы были покрыты все решения и все условия. Получается объединением наборов тестов по методу покрытия решений и покрытия условий. Еще более серьезное тестирование это комбинированное покрытие. Комбинированное покрытие требует, чтобы хотя бы один раз выполнялись все возможные комбинации условий.
В нашем примере определения координатной четверти для комбинированного покрытия необходимо выполнить 16 тестов Рисунок Соотношения между различными покрытиями. Рисунок Для программ содержащих только одно условие на каждом принятии решения минимальным является набор тестов покрытие решений. Для программ содержащих более одного условия на принятии решения минимальным является тест на покрытие условий решений. Отладка программы
Отладка это процесс исправления обнаруженных ошибок. Если программа работает не так как должна, необходимо выяснить местоположение ошибки, проверить правильность работы каждой части программы. Для этой цели удобно использовать встроенный отладчик, который имеется в большинстве языков программирования. Стандартные возможности отладчика просмотр списка переменных и выражений их типов и значений во время выполнения программы использование контрольных точек точек
останова выполнение программы до курса пошаговое выполнение программы просмотр стека вызванных подпрограмм В некоторых языках программирования отладчик включает дополнительные функции доступ к регистрам и флагам процессора доступ к различным видам памяти отслеживание сообщений Windows запись информации о фатальных ошибках 5. Виды и содержание документации, составляемый в соответствии с ЕСПД на этапах разработки технического задания. ТЕХНИЧЕСКОЕ
ЗАДАНИЕ ГОСТ 19.201-78 Согласно ГОСТу, настоящий стандарт переизданный в ноябре 1987 г. устанавливает порядок построения и оформления технического задания на разработку программы или программного изделия для вычислительных машин, комплексов и систем независимо от их назначения и области применения. Надо быть предельно внимательным и осторожным, создавая его, т.к. зачастую умело и грамотно составленное ТЗ определяет успех всей работы. Именно ТЗ согласовывается с
Заказчиком, который обычно стремится внести как можно больше противоречивых и завышенных требований. Задача же Исполнителя - наоборот, облегчить себе жизнь. Но после того, как подписи с обеих сторон поставлены, переигрывать что-либо поздно. 1. Общие положенияТехническое задание оформляют на листах формата А4 и или А3, как правило, без заполнения полей листа.
Номера листов страниц проставляют в верхней части листа над текстом. Для внесения изменений и дополнений в техническое задние на последующих стадиях разработки программы или программного изделия выпускают дополнение к нему. Согласование и утверждение дополнения к техническому заданию проводят в том же порядке, который установлен для технического задания. Техническое задание должно содержать следующие разделы наименование и область
применения основание для разработки назначение разработки технические требования к программе или программному изделию технико-экономические показатели стадии и этапы разработки порядок контроля и приемки приложения. В зависимости от особенностей программы или программного изделия допускается уточнять содержание разделов, вводить новые разделы или объединять отдельные из них. 2. Содержание разделовВ разделе Наименование и область применения указывают наименование, краткую характеристику
области применения программы или программного изделия и объекта, в котором используют программу или программное изделие. В разделе Основание для разработки должны быть указаны документ документы , на основании которых ведется разработка организация, утвердившая этот документ, и дата его утверждения наименование и или условное обозначение темы разработки. Применительно к специфике учебного процесса основанием может служить задание на курсовое проектирование,
приказ по институту от за N договор за N и т.п. В разделе Назначение разработки должно быть указано функциональное и эксплуатационное назначение программы или программного изделия. Ограничиться здесь можно одной-двумя фразами. Главное - четко определить, для чего нужна эта программа. Например Программа представляет собой ядро автоматизированного рабочего места
АРМ разработчика непрерывных линейных систем автоматического управления САУ , позволяющее пользователю решать задачи анализа простых моделей. Раздел Технические требования к программе или программному изделию должен содержать следующие подразделы требования к функциональным характеристикам требования к надежности условия эксплуатации требования к составу и параметрам технических средств требования к информационной и программной совместимости требования
к маркировке и упаковке требования к транспортированию и хранению специальные требования. Иными словами, здесь начинается конкретика. Описывается то, что должна делать программа и как она должна выглядеть. Требования к функциональным характеристикам. Здесь должны быть указаны требования к составу выполняемых функций, организации входных и выходных данных, временным характеристикам и т.п. Например Программа должна позволять вычислять строить создавать
Исходные данные текстовый файл с заданной Выходные данные графическая и текстовая информация - результаты анализа системы текстовые файлы - отчеты о диагностика состояния системы и сообщения о всех возникших ошибках. Требования к надежности. Должны быть указаны требования к обеспечению надежного функционирования обеспечение устойчивого функционирования, контроль входной и выходной информации, время восстановления после отказа и т.п Здесь выгадать что-то сложно. В лучшем случае может пройти вариант, при котором ваша
программа работает только с абсолютно корректными данными. Обычно Заказчик на это не идет, но попробовать можно. Например Программа должна работать с заданной расширенной матрицей инциденций исследуемого графа в соответствии с алгоритмом функционирования, выдавать сообщения об ошибках при неверно заданных исходных данных , поддерживать диалоговый режим в рамках предоставляемых пользователю возможностей.
Условия эксплуатации. Должны быть указаны условия эксплуатации температура окружающего воздуха, относительная влажность и т.п. для выбранных типов носителей данных , при которых должны обеспечиваться заданные характеристики, а также вид обслуживания, необходимое количество и квалификация персонала. С этим пунктом сложностей обычно не возникает. К сожалению, пункт о профессиональности пользователя Заказчиком подразумевается обязательно. Это, конечно, лишний повод придраться к вашей программе.
Впрочем, здесь можно ограничиться фразами вида Условия эксплуатации программы совпадают с условиями эксплуатации ПЭВМ IBM PC и совместимых с ними ПК , Программа должная быть рассчитана на непрофессионального пользователя и т.п. Требования к составу и параметрам технических средств. Указывают необходимый состав технических средств с указанием их технических характеристик.
Здесь главное - ничего не забыть и все предусмотреть, с одной стороны а то подсунут какой-нибудь IBM PC XT с монохромным дисплеем и без мыши , а с другой - не переборщить с повышенными требованиями, иначе Заказчик найдет более покладистого Исполнителя. Например Необходимо наличие IBM PC - совместимого ПК с графическим адаптером EGA VGA . Необходимое дисковое пространство - не менее 600
Кб, объем свободной оперативной памяти - не менее 400 Кб. Желательно наличие драйвера EMS и манипулятора типа мышь . Требования к информационной и программной совместимости. Особенности те же, что и в предыдущем пункте. Здесь должны быть указаны требования к информационным структурам на входе и выходе и методам решения, исходным кодам, языкам программирования.
При необходимости должна обеспечиваться защита информации и программ. Например Программа должна работать автономно под управлением ОС MS DOS версии не ниже 3.3. Базовый язык программирования - Turbo Pascal 6.0. Требования к маркировке и упаковке и требования к транспортированию и хранению являются достаточно экзотическими. В общем случае здесь указывают требования к маркировке программного изделия,
варианты и способы упаковки. А в требованиях к транспортированию и хранению должны быть указаны для программного изделия условия транспортирования, места хранения, условия хранения, условия складирования, сроки хранения в различных условиях. Специальные требования - это весьма ответственная вещь. Их лучше, по возможности, всячески избегать. И заявить об этом сразу. Например Специальных требований к временным характеристикам программы не предъявляется.
Специальных требований к емкостным характеристикам программы не предъявляется. Технико-экономические показатели. Этот самый сложный для программиста пункт есть далеко не всегда. Он нужен прежде всего тогда, когда вашей целью является обоснование огромной эффективности и важности выполняемой работы. На Заказчика этот пункт действует, обычно, очень хорошо. По крайне мере, это лучшее обоснование сроков и денежных сумм разработки.
В этом разделе должны быть указаны ориентировочная экономическая эффективность, предполагаемая годовая потребность например предполагаемое число обращений к комплексу в целом в год - 365 сеансов работы , экономические преимущества разработки по сравнению с лучшими отечественными и зарубежными образцами или аналогами. Помимо этого, желательно привести определение как сметной стоимости разработки программы, так и определение трудоемкости программирования.
Стадии и этапы разработки об этом подробнее будет сказано ниже устанавливают необходимые стадии разработки, этапы и содержание работ перечень программных документов, которые должны быть разработаны, согласованы и утверждены , а также, как правило, сроки разработки и определяют исполнителей. Здесь описываются стандартные этапы. Главное - грамотно определиться со сроками. По возможности, старайтесь равномерно распределить этапы по срокам и суммам .
Помните, что не все проекты доживают до последней стадии. А отчеты должны быть по каждому этапу. Помните также, что больше всего времени займет рабочий проект. Если вы не успеете сделать в срок документацию, то Заказчик имеет полное право вообще не принять работу со всеми вытекающими последствиями. Основными и непременными стадиями и этапами являются само техническое задание, эскизный проект, технический
и рабочий проекты. Эскизный проект. На этой стадии детально разрабатываются структуры входных и выходных данных, определяется форма их представления. Разрабатывается общее описание алгоритма, сам алгоритм, структура программы. Разрабатываются план мероприятий по разработке и внедрению программы. Технический проект. Содержит разработанный алгоритм решения задачи а также методы контроля исходной информации. Здесь же разрабатываются средства обработки ошибок и выдачи диагностических сообщений, определяются
формы представления исходных данных и конфигурация технических средств. Рабочий проект. На этой стадии осуществляется программирование и отладка программы, разработка программных документов, программы и методики испытаний. Подготавливаются контрольно-отладочные примеры. Окончательно оформляются документация и графический материал. Обычно указывается, что в ходе разработки программы должна быть подготовлена следующая документация
текст программы описание программы программа и методика испытаний описание применения руководство пользователя. Это - стандартные требования. Если Заказчик соглашается с тем, что можно представить не весь этот список, то это означает несерьезность его намерений в отношении вас и вашего продукта. Графического материала может и не быть. Особенно тогда, когда вы не собираетесь докладывать о результатах своей работы. Но для серьезных проектов этот пункт обязателен.
Например В ходе разработки программы должен быть подготовлен следующий графический материал технико-экономические показатели структура программы формат представления входных данных программы общая схема алгоритма 2 листа основные вычислительные алгоритмы пример работы программы. В разделе Порядок контроля и приемки должны быть указаны виды испытаний и общие требования к приемке работы. Если возможно, то в этом пункте укажите, что контроль и приемка разработки осуществляются на
предоставляемой Заказчиком технике , иначе вас могут обязать принести технику с собой. Например Контроль и приемка разработки осуществляются на основе испытаний контрольно-отладочных примеров. При этом проверяется выполнение всех функций программы. В Приложениях к техническому заданию, при необходимости, приводят перечень научно-исследовательских и других работ, обосновывающих разработку схемы алгоритмов, таблицы, описания, обоснования, расчеты
и другие документы, которые могут быть использованы при разработке другие источники разработки. 6. Внедрение и эксплуатация программного изделия. Под внедрением понимается установка и настройка программного обеспечения, а также его тестирование и адаптация на рабочих местах клиента. В процессе внедрения можно выделить несколько основных этапов предпроектное обследование изучение специфики работы организации настройка программного продукта в соответствии с
результатами предпроектного обследования ввод программного продукта в тестовую эксплуатацию ввод программного продукта в штатный рабочий режим эксплуатации. Под эксплуатацией ПО понимается функциональная сложность - это разнообразие и полнота решения задачи с учетом изменения исходных данных надежность функционирования ПО - это относительно длительное получение без сбойных результатов трудоемкость эксплуатации - сложность исходных данных и результатов.
7. Надежность программного изделия. Надежность является составной частью более общего понятия - качества. Качественная программа не только надежна, но и компактна - совместима с другими программа ми, эффективна, удобна в сопровождении и вполне понятна. Надежность сложных комплексов программ определяется двумя факторами надежностью компонент ошибками в конструкции допущенными при проектировании и изготовлении. Этот фактор является преобладающим при определении надежности
ПО. Основные понятия теории надежности функционирования программ. Отказ при использовании программ - это нарушении при работоспособности программного изделия и его соответствия требованиям к технической документации. Отказ при выполнении программы может появиться как следствие нарушение кодов записи команд программы в памяти стирание или искажение данных в оперативной памяти или долговременной памяти ЭВМ нарушение нормального хода вычислительного процесса.
Во всех случаях программные отказы приводят к прекращении выдачи пользователю информации, к остановке управляющих воздействий на программу или значительному искажению содержания и темпа выдачи информации пользователю. Сбой при исполнении программ - это самоустраняющийся отказ не требующий внешнего вмешательства для замены отказавших компонент. Разница между отказом и сбоем определяется по временному показателю длительности восстановления после любого искажения программных данных или вычислительного процесса.
Критерии надежности программы. Приводимые критерии являются статическими и в том или ином виде учитываются временные показателями. В статическом смысле показателем надежности ПО служит вероятность того что программное обеспечение проработает без ошибки т.е. выводимая информация будет находиться в заданных приделах для исходных условиях в течении установленного интервала времени. Для оценки надежности восстановленных систем необходимо знать характеристики многократных систем многократных
отказов и восстановлений в процессе функционировании программ. Характеристики многократных отказов и восстановлений описываются следующими показателями 1. вероятность восстановления за некоторое время 2. плотность распределения времени восстановления 3. среднее время восстановления Объединение характеристик отказов и восстановлений происходит по следующим критериям 1. наработка на отказ - это время которое предшествует отказу 2. коэффициент готовности - это доля времени
полезной работы программы на достаточно большом интервале времени, содержащим отказы и восстановление. Оценка надежности ПО может быть получена в результате моделирования надежности ПО. Наиболее часто встречающиеся модели основаны на использовании интенсивности ошибок и времени тестирования, замеренных в процессе тестирования ПО на стадии готовности ПО. Время тестирования до обнаружения ошибки, время устранения ошибки и среднее время между отказами
наработка на отказ являются входными параметрами модели при моделировании надежности ПО. С этими параметрами модель затем используется для предсказания числа оставшихся ошибок т. к. создание 100 безошибочного ПО недостижимо , времени, необходимого для их устранения и ожидаемой наработки на отказ. Факторы, снижающие надежность функционирования программ. 1. искажение исходной информации поступающей от модулей входящих в
ПО 2. самоустраняющиеся отказы или сбои в аппаратуре ЭВМ 3. не выявленные ошибки в программе. 8. Технические, программные и криптографические средства защиты информации. Средства защиты информации можно разделить на технические программные криптографические. Технические средства защиты информации Техническими средствами защиты называются различные электронные и электронно-механические устройства, которые выполняют самостоятельно или в комплексе с другими средствами
некоторые функции защиты. К настоящему времени применяется значительное число различных аппаратных средств, причем они могут включаться практически во все устройства терминалы пользователей, устройства группового ввода-вывода данных, центральные процессоры, внешние запоминающие устройства, другое периферийное оборудование. Так, например, в терминалах пользователей наибольшее распространение получили устройства предназначенные для предупреждения несанкционированного включения терминала в работу различного рода замки и блокираторы
, обеспечения идентификации терминала схемы генерирования идентифицирующего кода и идентификации пользователя магнитные, индивидуальные карточки, дактилоскопические и акустические устройства опознавания и т.п Самостоятельную группу составляют аппаратные средства шифрования данных, которые к настоящему времени получили весьма широкое распространение за рубежом и, в настоящее время, внедряются в нашей стране. Так, например, Центральный банк России в 1992 г. закупил около трех тысяч устройств шифрования данных,
передаваемых по каналам телеграфной связи. Современные устройства шифрования могут сопрягаться с помощью стандартных интерфейсов практически с любым устройством, обеспечивая как шифрование, так и дешифрование данных. Кроме того, применяются вспомогательные средства защиты устройства уничтожения информации на магнитных носителях, устройства сигнализации о несанкционированных действиях и ряд других. Программные средства защиты информации Программными средствами защиты называются специальные программы,
которые включаются в состав программного обеспечения специально для осуществления функций защиты. Программные средства являются важнейшей частью механизма защиты информации. что обусловлено такими их достоинствами, как универсальность, простота реализации, гибкость, практически неограниченные возможности изменения и развития. К недостаткам программных средств относится необходимость расходования ресурсов процессора на их функционирование и возможность несанкционированного злоумышленного изменения, а также
тот факт, что программные средства защиты можно реализовать только в тех устройствах, в составе которых имеется процессор, хотя функции защиты программными средствами могут осуществляться и в интересах других структурных элементов. Поэтому программные средства защиты применяются в центральных процессорах, устройствах группового управления вводом-выводом данных, а также в аппаратуре связи в тех случаях, когда в их составе имеются процессоры. Известные на сегодняшний день программы защиты в соответствии с выполняемыми ими
функциями, можно разделить на следующие группы программы идентификации программы регулирования работы технических средств, пользователей, функциональных задач, элементов баз данных и т.д. программы шифрования защищаемых данных программы защиты программ операционных систем, систем управления базами данных, программ пользователей и др. вспомогательные программы уничтожение остаточной информации, формирование грифа секретности выдаваемых документов, ведение регистрационных журналов, имитация работы с нарушителем,
тестовый контроль механизма защиты и некоторые другие . Криптографические средства защиты информации Назначение и история Криптографические средства защиты. Криптографическими средствами защиты называются специальные средства и методы преобразования информации, в результате которых маскируется ее содержание. kryptos - тайный, logos - наука . История криптографии - ровесница истории человеческого языка.
Более того, первоначально письменность сама по себе была криптографической системой, так как в древних обществах ею владели только избранные. Священные книги Древнего Египта, Древней Индии тому примеры. С широким распространением письменности криптография стала формироваться как самостоятельная наука. Первые криптосистемы встречаются уже в начале нашей эры. Так, Цезарь в своей переписке использовал уже более-менее систематический шифр, получивший его имя.
Бурное развитие криптографические системы получили в годы первой и второй мировых войн. Начиная с послевоенного времени и по нынешний день появление вычислительных средств ускорило разработку и совершенствование кpиптогpафических методов. Почему проблема использования кpиптогpафических методов в настоящий момент особенно актуальна? С одной стороны, pасшиpилось использование компьютерных сетей, в частности глобальной сети Интернет, по которым передаются большие объемы информации государственного,
военного, коммерческого и частного хаpактеpа, не допускающего возможность доступа к ней посторонних лиц. С другой стороны, появление новых мощных компьютеров, технологий сетевых и нейронных вычислений сделало возможным дискредитацию криптографических систем еще недавно считавшихся практически не pаскpываемыми. Криптология занимается проблемой защиты информации путем ее преобразования Криптология разделяется на два направления - кpиптогpафию и кpиптоанализ.
Цели этих направлений прямо противоположны. Кpиптогpафия занимается поиском и исследованием математических методов пpеобpазования информации. Кpиптоанализ исследует возможности pасшифpовывания информации без знания ключей. Основные направления использования кpиптогpафических методов - передача конфиденциальной информации по каналам связи например, электронная почта , установление подлинности передаваемых сообщений, хранение информации документов, баз данных на носителях в зашифрованном виде.
Терминология Итак, криптография дает возможность преобразовать информацию таким образом, что ее прочтение восстановление возможно только при знании ключа. В качестве информации, подлежащей шифрованию и дешифрованию, будут рассматриваться тексты, построенные на некотором алфавите. В качестве примеров алфавитов можно привести алфавит Z 33 - 33 буквы русского алфавита и пробел алфавит
Z 256 - символы, входящие в стандартные коды ASCII и КОИ-8 бинарный алфавит - Z 2 0,1 восьмеричный алфавит или шестнадцатеричный алфавит Текст - упорядоченный набор из элементов алфавита. Шифрование - преобразовательный процесс исходный текст, который носит также название открытого текста, заменяется шифрованным текстом. Дешифрование - обратный шифрованию процесс.
На основе ключа шифрованный текст преобразуется в исходный. Ключ - информация, необходимая для беспрепятственного шифрования и дешифрования текстов. Криптосистема - семейство преобразований открытого текста с использованием ключа Современная криптография включает в себя четыре крупных раздела 1. Симметричные криптосистемы. 2. Криптосистемы с открытым ключом.
3. Системы электронной подписи. 4. Управление ключами. Криптосистемы разделяются на симметричные и с открытым ключом. В симметричных криптосистемах и для шифрования, и для дешифрования используется один и тот же ключ. В системах с открытым ключом используются два ключа - открытый и закрытый, которые математически связаны друг с другом. Информация шифруется с помощью открытого ключа, который доступен всем желающим, а расшифровывается
с помощью закрытого ключа, известного только получателю сообщения. Термины распределение ключей и управление ключами относятся к процессам системы обработки информации, содержанием которых является составление и распределение ключей между пользователями. Электронной цифровой подписью называется присоединяемое к тексту его криптографического преобразования, которое позволяет при получении текста другим пользователем проверить авторство и подлинность сообщения.
Криптостойкостью называется характеристика шифра, определяющая его стойкость к дешифрованию без знания ключа т.е. криптоанализ . Имеется несколько показателей криптостойкости, среди которых количество всех возможных ключей среднее время, необходимое для криптоанализа. Эффективность шифрования с целью защиты информации зависит от сохранения тайны ключа и криптостойкости шифра. Основные требования к криптосистемам зашифрованное сообщение должно поддаваться чтению только
при наличии ключа число операций, необходимых для расшифровывания информации путем перебора всевозможных ключей должно иметь строгую нижнюю оценку и выходить за пределы возможностей современных компьютеров с учетом возможности использования сетевых вычислений знание алгоритма шифрования не должно влиять на надежность защиты незначительное изменение ключа должно приводить к существенному изменению вида зашифрованного сообщения даже при использовании одного и того же ключа дополнительные биты, вводимые в сообщение в
процессе шифрования, должен быть полностью и надежно скрыты в шифрованном тексте не должно быть простых и легко устанавливаемых зависимостью между ключами, последовательно используемыми в процессе шифрования любой ключ из множества возможных должен обеспечивать надежную защиту информации алгоритм должен допускать как программную, так и аппаратную реализацию, при этом изменение длины ключа не должно вести к качественному ухудшению алгоритма шифрования. 9. Метрология программного изделия.
МЕТРОЛОГИЯ - наука об измерениях, методах и средствах обеспечения их единства и способах достижения требуемой точности. Нет ни одной области практической деятельности человека, где можно было бы обойтись без количественных оценок, получаемых в результате измерений. Человек появляется на свет, еще не имеет имени, но нам становятся известны его рост, вес, температура - уже в первые минуты жизни ему приходится сталкиваться с линейкой, весами, термометром.
Каждое утро, выходя из дома, мы оцениваем тем- ратуру воздуха на улице и одеваем при необходимости шляпу или ушанку, пальто ипи шубу. Весь свой день мы расписываем по часам и пытаемся выполнить этот план, периодически поглядывая на часы. Стоя перед лужей и решая - прыгнуть через нее или обойти, мы соизмеряем длину лужи и свои возможности. Это и есть измерение нахождение соотношения между измеряемой величиной длиной лужи и единицей , этой величины возможной длиной прыжка .
Современная метрология как научная дисциплина пережила этап младенчества, когда она занималась описанием своих и зарубежных единиц измерений, этап юности, когда ее называли наукой об измерениях, приводимых к эталонам, повзрослела и стала разделом могущественной физики, овладела математическими методами и возглавила приборостроение, которое обеспечивает нас средствами измерений средствами объективной оценки окружающего мира. Академик А.П. Александров писал Метрология является острой необходимостью нашего времени
- от нее зависит возможность установления фундаментальных основ физического мировоззрения, от нее же в сметной мере зависит благосостояние трудящихся . В настоящее время различают теоретическую метрологию, рассматривающую общие теоретические проблемы измерений, историческую метрологию, курс которой читается в Историко-архивном институте, законодательную метрологию, охватывающую комплексы взаимосвязанных общих правил, требований и норм, а также другие вопросы, нуждающиеся
в регламентации и контроле со стороны государства, и, наконец, прикладную метрологию, занимающуюся вопросами практического применения методов и средств измерений. Метрология приобретает все большее значение в повышении эффективности производства, технического уровня и качества продукции. Поэтому вопросами развития метрологии, совершенствованию деятельности метрологических организации и служб должно уделяться самое пристальное внимание руководителями производственных предприятий,
научно производственных объединений и научно исследовательских институтов. Решение вопросов метрологического обеспечения дает наибольший эффект и требует при этом наименьших затрат тогда, когда осуществляется на начальных этапах создания новых видов продукции, разработки и освоения технологических процессов, организации производства. Работы по обеспечению единства измерений в России осуществляются на основе
Закона Российской Федерации Об обеспечении единства измерений . Нормативная база государственной системы обеспечения единства измерений ГСИ - комплекс нормативных документов, включающих в себя государственные стандарты и другие нормативные документы, определяющие порядок передачи размера единиц величин на всю территорию России и порядок проведения испытаний, поверки и калибровки средств измерений.
Технической основой ГСИ является государственная эталонная база России. Эталонная база России состоит из 1176 государственных первичных и специальных эталонов. Госстандарт России осуществляет государственный метрологический контроль и надзор. Государственный метрологический контроль включает утверждение типа средств измерений поверку средств измерений лицензирование деятельности юридических и физических лиц по изготовлению, ремонту, продаже
и прокату средств измерений. Федеральный закон О лицензировании отдельных видов деятельности . Государственный метрологический надзор осуществляется за выпуском, состоянием и применением средств измерений, аттестованными методиками выполнения измерений, эталонами единиц величин, соблюдением метрологических правил и норм за количеством товаров, отчуждаемых при совершении торговых операций за количеством фасованных товаров в упаковках любого вида при их расфасовке и продаже 10.
Совершенствование программного изделия и сопровождение программного продукта. Критерии качества этапа проектирования включают, прежде всего, сложность создания комплекса программ и проверки его адекватности поставленным целям. Сложность разработки зависит от исходной задачи и используемых алгоритмов, от структуры данных, программных модулей и комплекса программ в целом и т.д. Хотя сложные при проектировании программы чаще всего характеризуются высокой сложностью функционирования,
встречаются программы, которые весьма сложны при разработке например, вследствие весьма ограниченных ресурсов реализующей ЭВМ , однако относительно просто эксплуатируются. Измерение сложности комплексов программ с позиции разработки является весьма трудной проблемой. Показатели сложности разработки комплексов программ - одна из наименее исследованных областей анализа критериев качества. Корректность программ и степень адекватности их функциональных возможностей поставленным
целям и техническим заданиям является важнейшим критерием в процессе разработки и испытаний комплексов программ. Для формализации этого критерия используются понятия и формализованные характеристики эталона, которому должна соответствовать программа. Эти характеристики определяются техническим заданиям на комплекс программ и спецификациями на его компоненты. Обеспечение корректности программ по всем заданным параметрам и компонентам требует их тщательной формализации
и определения допусков возможных отклонений. Метрики этого критерия весьма разнообразны в соответствии с требованиями технических заданий на различные комплексы программ. На этапе проектирования основные затраты составляет трудоемкость создания программ заданной сложности и корректности. Трудоемкость зависит от квалификации специалистов, технологии проектирования, степени автоматизации разработки и испытаний и т.д. Совокупные затраты труда на создание комплекса программ
и их распределения по фазам проектирования могут влиять на эксплуатационные характеристики программ. При измерении трудоемкости могут применяться обычные экономические показатели, некоторые трудности встречаются при выделении состава специалистов, труд которых следует учитывать как затраты на создание программ. Критерии качества этапа эксплуатации. В процессе эксплуатации комплекса программ важнейшим конструктивным критерием качества является его функциональная сложность, разнообразие и полнота решения
целевых задач. Этот критерий не является полностью конструктивным и, так же как и некоторые другие, в той или иной степени отражает назначение и функциональные характеристики комплекса программ. Сложность программ в процессе эксплуатации проявляется в разнообразии и диапазоне изменения различных результатов на выходе программ с учетом разнообразия исходных данных. При эксплуатации доминирующей является сложность поведения комплекса программ относительно характеристик
входа-выхода, и его внутреннее содержание может считаться как второстепенное. Однако сложность поведения комплекса программ и его функциональные характеристики могут завесить от особенностей конструктивной реализации на конкретной ЭВМ, от ресурсов памяти и производительности ВС и от других факторов, что приводит к необходимости их учета при анализе сложности. Ниже рассматриваются несколько подходов к ее оценке в зависимости от задач
исследования. Для многих комплексов программ важнейшим эксплуатационным критерием качества является надежность безотказность функционирования. Этот показатель характеризует относительную длительность получения корректных достоверных результатов или вероятность правильных не искаженных за доступные пределы выходных данных. Для этого критерия качества программ могут использоваться различные показатели, хорошо разработанные в теории надежности аппаратных систем.
Основные затраты при эксплуатации комплексов программ состоят в использовании ресурсов памяти и производительности ВС, на которых реализуются программы. С этой стороны качество программ характеризуется степенью или эффективностью использования ресурсов ВС для решения конкретной задачи определенной сложности с необходимой надежностью. Этот критерий учитывает емкость используемой памяти и длительность решения некоторой задачи при различных методах использования ресурсов ВС. Качество комплексов программ по внешним связям и взаимодействию
с абонентами можно характеризовать объемом исходных и результирующих данных. Состав, сложность структуры и количество данных, которыми обменивается комплекс программ с внешней средой, в некоторой степени характеризует его функциональную сложность, однако их целесообразнее рассматривать как самостоятельный критерий качества. Показатели должны учитывать интенсивности потоков и количество информации на входе и выходе системы, размерность, диапазоны изменения, особенности кодирования и другие
параметры обменных данных. Критерии качества и определяющие их факторы на основных этапах жизненного цикла комплексов программ Этапы жизненного цикла Проектирование Эксплуатация Сопровождение Основные критерии качества комплекса программ 1. Сложность создания программ 2. Корректность программ 3. Трудоемкость разработки программ 1. Функциональная сложность комплекса программ 2.
Надежность функционирования 3. Эффективность использования ресурсов ВС 4. Объем исходных и результирующих данных 1. Способность к модернизации программ 2. Мобильность программ относительно типов ВС 3. Трудоемкость изучения и модификации комплексов программ Основные факторы, определяющие качество 1. Структурная упорядоченность программ и данных 2. Степень стандартизации структуры модулей и переменных 3.
Документированность компонент и комплекса 4. Методическая обеспеченность технологии проектирования 5. Степень комплексной автоматизации технологии проектирования 6. Уровень языков спецификаций, программирования и отладки 7. Квалификация специалистов и методы организации работ 1. Корректность постановки задач 2. Полнота и точность спецификаций 3.
Уровень языков программирования 4. Полнота тестирования программ 5. Степень помехозащищенности программ 6. Документированность для эксплуатации 1. Структурная упорядоченность комплекса программ и данных 2. Степень стандартизации структуры модулей и переменных 3. Документированность для модификации 4. Уровень языков программирования 5.
Степень комплексной автоматизации технологии проектирования 6. Обеспеченность контроля изменений версий и распространения копий В таблице перечислены факторы, в наибольшей степени влияющие на конструктивные критерии качества эксплуатации. Эти факторы довольно разнообразны и отражаются на комплексе программ прежде всего при его создании. Их можно рассматривать как причины, приводящие к определенным значениям показателей качества эксплуатации,
а также как самостоятельные частные критерии эффективности проектирования и в некоторой степени эксплуатации. Однако, как явные локальные критерии оценки эксплуатации большинство факторов обычно не рассматривается. Некоторые из приведенных факторов например, степень помехозащищенности программ, уровень языков программирования одновременно воздействуют на несколько показателей качества, изменяя их в противоположных направлениях. Это приводит к проявлению ряда оптимизационных задач, решение которых должно обеспечить достижение
необходимого качества по нескольким критериям при воздействии противоречивых факторов. Критерии качества этапа сопровождения близки по содержанию к критериям этапа проектирования. Однако имеются значительные особенности, влияющие на качество программ с позиции их развития и модификации. Способность к модернизации комплексов программ определяется четкостью их структурного построения и структурой межмодульных связей. Кроме того, на этот критерий влияет метод распределения ресурсов
ВС и наличие резервов для развития программ. Этот критерий пока слабо формализован и в основном определяется степенью регулярности, упорядоченности и стандартизованности структур данных, программных модулей и комплекса в целом. Мобильность комплекса программ относительно изменения типа, структуры и системы команд вычислительной машины характеризует возможность сохранения и эффективного использования эксплуатируемых программ в процессе развития аппаратуры ЭВМ. Трудоемкость переноса программ с одних технических средств
на другие зависит от специфических различий этих средств длина слова, емкость памяти, структура команд и т.д а также от структуры комплекса программ, степени стандартизации языка программирования и автоматизации технологии проектирования и т.д. Показатели мобильности программ в той или иной степени связываются с трудоемкостью переноса программ на новый тип машины относительно трудоемкости полного проектирования аналогичного комплекса. Трудоемкость изучения и модификации программ при сопровождении определяется
степенью документированности комплекса программ и его структурным построением, уровнем языка программирования и некоторыми другими факторами. Этот критерий в значительной степени влияет на длительность ЖЦ комплекса программ. Целесообразность и длительность использования, модернизации и переноса программ сохраняется до тех пор, пока не станет рентабельной новая разработка. При этом программы проходят через ряд развивающихся версий, вследствие чего этапы эксплуатации и модернизации
идут параллельно. В трудоемкости сопровождения могут также учитываться затраты на тиражирования программ, на выявление и корректировку ошибок, на распределение сведений о проверенных изменениях и т.д. Основные факторы. Влияющие на критерии качества сопровождения, несколько отличаются от факторов разработки. На этом этапе особое значение приобретает контроль проведенных модернизаций, внесения изменений, состояний версий, их тиражирования и эксплуатаций. Эти особенности влияют на технологию проектирования, структуру
программ и методику их изменения. Заключая обзор основных конструктивных критериев качества комплексов программ и влияющих на них факторов, следует выделить особо временные показатели ЖЦ программ длительность проектирования, продолжительность эксплуатации очередной версии и длительность проведения каждой модификации. Продолжительность этих работ в ряде случаев может быть более важным критерием, чем трудоемкость. В некоторых случая суммарная длительность эффективной эксплуатации является доминирующим
критерием качества программ. Для каждой из разработок целесообразно проводить ранжирование критериев и факторов на этапах ЖЦ комплекса программ. Реальная ограниченность некоторых ресурсов или факторов может значительно влиять на их значение в конкретных разработках. Управление качеством комплексов программ. На смену интуитивным оценкам показателей качества программ приходят более или менее точные измерения, и проявилась необходимость регулярного достоверного контроля
показателей и управления качеством ПО. Управление качеством предполагает формализацию технологии проектирования комплексов программ, а также независимое измерение, контроль и анализ показателей качества программ и влияющих на них факторов. Автономность управления качеством от управления разработкой способствует объективности измерения показателей и более точному контролю достигаемых значений. Управление качеством включает Анализ системных требований к комплексу программ и ранжирование показателей
качества с выделением обязательных и желательных значений характеристик Разработку методик и стандартов контроля степени выполнения заданной технологии модульно-иерархического проектирования комплекса программ и его компонент Создание методов, средств и технологии объективного измерения и поэтапного контроля степени выполнения заданных требований к качеству программ Создание средств инструментальной технологической поддержки автоматизации программирования, отладки
и испытаний, обеспечивающих создание комплекса создание комплекса программ с заданными показателями качества Организацию коллектива специалистов и организацию процесса проектирования с целевой задачей максимального удовлетворения требований заказчика к качеству комплекса программ. Управление качеством можно разделить на подготовительную фазу и фазу активного контроля и управления. На подготовительной фазе разрабатываются стандарты.
Методы и средства, потенциально способствующие созданию комплекса программ с заданными характеристиками качества. Выбор и подготовка технологии проектирования в значительной степени определяют последующее качество программ. Активный контроль и управление качеством, включающие организационные, методические и технологические мероприятия, необходимы в течение всего ЖЦ комплекса программ с оценкой затрат на достижение требуемого уровня качества.
Важнейшим для качества программ является этап системного анализа, формирования технического задания и общей спецификации на комплекс программ. При этом для управления качеством комплексов программ любого назначения необходимо учитывать два типа ограничений. Первый тип ограничений характеризует уровень современных значений теории и методов решения поставленных задач как с позиции формализации основных функциональных алгоритмов, так и с точки зрения методов структурного
построения сложных систем и технологии их проектирования. Второй тип ограничений составляют в основном технические параметры средств, на которых предполагается реализовать комплекс программ, трудовые и финансовые ресурсы, которые могут быть выделены на разработку и эксплуатацию программ. При последующем изложении учитываются как наиболее универсальные только ограничения второго типа. 11. Предпродажная подготовка и сопровождение программного продукта.
Предпродажная подготовка После проведения этапа тестирования и выполнения приемочного теста составляются акты, которые фиксируют готовность нормативно-справочной документации и проверку программного продукта на конкретных примерах. При необходимости составляет протокол об отступлениях от проекта. Перед выпуском коммерческой версии многие фирмы создают демо-версию программы или компьютерные ролики программы. Демо-версия представляет собой урезанную версию программы.
Она позволяет судить об интерфейсе программы и ее возможностях, позволяет пользователю опробовать программу, но не позволяет полноценно работать с ней. Например, в демо-версии могут быть недоступны некоторые пункты меню или могут быть наложены ограничения на объем данных и сроки использования программного продукта. Ролик программы представляет собой последовательность экранов программы с пояснениями. Он так же позволяет судить о внешнем виде программы и ее возможностях.
Демо-версии и ролики, как правило, распространяются бесплатно. На этапе предпродажной подготовки уместно начать рекламную компанию в средствах массой информации в газетах, в сети internet. Виды обслуживания при продаже программного продукта При продаже программного продукта возможны следующие виды обслуживания Помощь в выборе аппаратуры Установка сопутствующего программного обеспечения
Инсталляция программы Обучение персонала Помощь в выборе аппаратуры Фирма-разработчик может помочь заказчику с выбором персональных компьютеров, различных периферийных и сетевых устройств. Предоставить информацию о типах персональных компьютеров оптимальных для разработанного программного обеспечения. Установка сопутствующего программного обеспечения Если существует программное обеспечение, которое удобно или необходимо использовать совместно с разработанным
программным продуктом, фирма-разработчик может так же обеспечить его установку. Инсталляция программы Первый вариант - фирма-разработчик может сама выполнить инсталляцию и настройку программы. Достоинство этот вариант удобен для пользователя, а также позволяет максимально обеспечить Ваши авторские права. Например, вы может поставить версию программу, которую невозможно будет переносить на другой компьютер, т.к. она привязана к номеру BIOS.
Второй вариант - пользователям могут быть переданы установочные диски с программой SETUP. Ее установку и настройку пользователь выполняет самостоятельно. Достоинство пользователь может сам сможет инсталлировать программу в случае сбоя, переустановки операционной системы, на новом компьютере. Обучение персонала. Если программа достаточно сложная, имеет нюансы ввода информации, желательно провести обучение персонала.
Это позволит уделять меньше внимания этапу сопровождения, а так же избежать ошибок со стороны пользователя. Если разработчики создают программное обеспечение для какой-то конкретной организации предпродажное обслуживание должно быть обсуждено еще до начала проектирования и включено в стоимость программного продукта. Сопровождение программных продуктов. После сдачи программного комплекса в эксплуатацию начинается этап сопровождения программного продукта. По времени это самый продолжительный этап.
Зачастую он оказывается и достаточно трудоемким. В период сопровождения программного продукта возможны 3 вида работы исправление ошибок помощь в эксплуатации модификация программы Исправление ошибок. В процессе эксплуатации могут быть обнаружены ошибки, которые не были найдены на этапах тестирования и опытной эксплуатации. В этом случае приходится возвращаться на этап тестирования и отладки, а так же выполнять повторную инсталляцию программы.
Помощь в эксплуатации. В процессе эксплуатации у пользователя могут возникнуть какие-либо вопросы, с которыми он обращается к программной документации, справочной системе или непосредственно к разработчику. Разработчик может значительно сократить объем работы с пользователем, если грамотно составит программную документацию, а так же проведет предварительное обучение персонала. Модификация программы. В процессе эксплуатации у пользователя могут возникнуть новые потребности или
он обнаружит, что не включил что-либо в техническое задание. Пользователь может попросить или потребовать если техническое задание размыто внести какие-либо изменения. Рекомендуется еще на стадии проектирования составлять план модификации и наращивания программы. Трудности при сопровождении 1. Во время сопровождения разработчики как правило начинают работу над новым проектом, заняты решением новой задачи и естественно забывают детали прошлого проекта.
Для основательного забывания деталей достаточно 1-2 месяцев, а через 6 месяцев вспомнить детали проекта уже очень сложно. 2. В крупных фирмах сопровождением программных продуктов часто занимаются люди не принимавшие участие в разработке программы. III. Разработка программного продукта и сопровождающей его документации. 1.1 Постановка задачи Составить программу и оттестировать ее по методу эквивалентных разбиений указать возможные ошибки . Тесты составить только для неправильных классов эквивалентности.
Пусть имеется несколько функций одного аргумента Х. Для каждой из них требуется распечатать таблицу значений на некотором отрезке. Отрезок a,b для каждой функции свой, также для каждой задан шаг изменения аргумента dX. Функции F1 X X sin X a 0.0 b 1.0 dX 0.1 F2 X X cos X a 0.5 b 2.1 dX 0.2 F3 X a 2.0 b 4.75 dX 0.25 1.2
Метод тестирования программы Эквивалентное разбиение. Хороший тест имеет приемлемую вероятность обнаружения ошибки и что исчерпывающее входное тестирование программы невозможно. Следовательно, тестирование программы ограничивается использованием небольшого подмножества всех возможных входных данных. Тогда, конечно, хотелось бы выбрать для тестирования самое подходящее подмножество т.е. подмножество с наивысшей вероятностью обнаружения большинства ошибок .
Правильно выбранный тест этого подмножества должен обладать двумя свойствами 1. уменьшать, причем более чем на единицу, число других тестов, которые должны быть разработаны для достижения заранее определенной цели приемлемого тестирования 2. покрывать значительную часть других возможных тестов, что в некоторой степени свидетельствует о наличии или отсутствии ошибок до и после применения этого ограниченного множества значений входных данных. Указанные свойства, несмотря на их кажущееся подобие, описывают два различных
положения. Во-первых, каждый тест должен включать столько различных входных условий, сколько это возможно, с тем чтобы минимизировать общее число необходимых тестов. Во-вторых, необходимо пытаться разбить входную область программы на конечное число классов эквивалентности так, чтобы можно было предположить конечное, не абсолютное уверенно , что каждый тест, являющийся представителем некоторого класса. Иными словами, если один тест класса эквивалентности обнаруживает ошибку, то следует
ожидать, что и все другие тесты этого класса эквивалентности будут обнаруживать ту же самую ошибку. Наоборот, если тест не обнаруживает ошибки, то следует ожидать, что ни один тест этого класса эквивалентности не будет обнаруживать ошибки в том случае, когда некоторое подмножество класса эквивалентности не попадает в пределы любого другого класса эквивалентности, так как классы эквивалентности могут пересекаться . Эти два положения составляют основу методологии тестирования по принципу черного ящика, известной как
эквивалентное разбиение. Второе положение используется для разработки набора интересных условий, которые должны быть протестированы, а первое - для разработки минимального набора тестов, покрывающих эти условия. Разработка тестов методом эквивалентного разбиения осуществляется в два этапа 1 выделение классов эквивалентности и 2 построение тестов. Выделение классов эквивалентности. Классы эквивалентности выделяются путем выбора каждого входного условия обычно это предложение или
фраза в спецификации и разбиением его на две или более групп. Для проведения этой операции используют таблицу. Входные условия Правильные классы эквивалентности Неправильные классы эквивалентности Заметим, что различают два типа классов эквивалентности правильные классы эквивалентности, представляющие правильные входные данные программы, и неправильные классы эквивалентности, представляющие все другие
возможные состояния условий т.е. ошибочные входные значения . Таким образом, придерживаются одного из принципов о необходимости сосредоточивать внимание на неправильных или неожиданных условиях. Если задаться входными или внешними условиями, то выделение классов эквивалентности представляет собой в значительной степени эвристический процесс. При этом существует ряд правил 1. Если входное условие описывает область значений например целое данное
может принимать значения от 1 до 999 , то определяются один правильный класс эквивалентности 1 значение целого данного 999 и два неправильных значение целого данного 1 и значение целого данного 999 . 2. Если входное условие описывает число значений например, в автомобиле могут ехать от одного до шести человек , то определяются один правильный класс эквивалентности и два неправильных ни одного и более шести человек . 3. Если входное условие описывает множество входных значений и есть основание полагать,
что каждое значение программы трактует особо например, известны способы передвижения на АВТОБУСЕ, ГРУЗОВИКЕ, ТАКСИ, ПЕШКОМ или МОТОЦИКЛЕ , то определяется правильный класс эквивалентности для каждого значения и один неправильный класс эквивалентности например, НА ПРИЦЕПЕ . 4. Если входное условие описывает ситуацию должно быть например, первым символом идентификатора должна быть буква , то определяются один правильный класс эквивалентности первый символ - буква и один
неправильный первый символ - не буква . 5. Если есть любое основание считать, что различные элементы класса эквивалентности трактуются программой неодинаково, то данный класс эквивалентности разбивается на меньшие классы эквивалентности. Построение тестов. Второй шаг заключается в использовании классов эквивалентности для построения тестов. Этот процесс включает в себя 1. Назначение каждому классу эквивалентности уникального номера.
2. Проектирование новых тестов, каждый из которых покрывает как можно большее число непокрытых правильных классов эквивалентности, до тех пор пока все правильные классы эквивалентности не будут покрыты только не общими тестами. 3. Запись тестов, каждый из которых покрывает один и только один из непокрытых неправильных классов эквивалентности, до тех пор пока все неправильные классы эквивалентности не будут покрыты тестами. Причина покрытия неправильных классов эквивалентности индивидуальными тестами состоит в том, что определенные
проверки с ошибочными входами скрывают или заменяют другие проверки с ошибочными входами. Например, спецификация устанавливает тип книги при поиске ВЫЧИСЛИТЕЛЬНАЯ ТЕХНИКА, ПРОГРАММИРОВАНИЕ или ОБЩИЙ и количество 1-9999 . Тогда тест XYZ 0 отображает два ошибочных условия неправильный тип книги и количество и, вероятно, не будет осуществлять проверку количества, так как и программа может ответить
XYZ - НЕСУЩЕСТВУЮЩИЙ ТИП КНИГИ и не проверять остальную часть входных данных. Пример Предположим, что при разработке компилятора для подмножества языка Фортран требуется протестировать синтаксическую проверку оператора DIMENSION. Спецификация приведена ниже. В спецификации элементы, написанные латинскими буквами, обозначают синтаксические единицы, которые в реальных операторах должны быть заменены соответствующими значениями,
в квадратные скобки заключены необязательные элементы, многоточие показывает, что предшествующий ему элемент может быть повторен подряд несколько раз. Оператор DIMENSION используется для определения массивов. Форма оператора DIMENSION DIMENSION ad ,ad , где ad есть описатель массива в форме n d ,d , n - символическое имя массива, а d - индекс массива. Символические имена могут содержать от одного до шести символов - букв или цифр,
причем первой должна быть буква. Допускается от одного до семи индексов. Форма индекса lb ub, где lb и ub задают нижнюю и верхнюю границы индекса массива. Граница может быть либо константой, принимающей значения от -65534 до 64535, либо целой переменной без индексов . Если lb определена, то она может иметь отрицательное, нулевое или положительное значение. Как и все операторы, оператор DIMENSION может быть продолжен на нескольких строках
Конец спецификации . Первый шаг заключается в том, чтобы идентифицировать входные условия и по ним определить классы эквивалентности. Классы эквивалентности в таблице обозначены числами. Следующий шаг - построение теста, покрывающего один или более правильных классов эквивалентности, Например, тест DIMENSION А 2 Покрывает классы 1,4,7,10,12,15,24,28,29 и 40. Далее определяется один или более тестов, покрывающих оставшиеся правильные классы эквивалентности.
Так, тест DIMENSION А12345 I,9,J4XXXX,65535,1,KLM, X 100 ,BBB -65534 100,0 1000,10 10,I 65535 покрывает оставшиеся классы. Перечислим неправильные классы эквивалентности и соответствующие им тесты 3 DIMENSION 5 DIMENSION 10 6 DIMENSION А234567 2 9 DIMENSION А.1 2 11 DIMENSION IA 10 13 DIMENSION B 14 DIMENSION
B 4,4,4,4,4,4,4,4 17 DIMENSION B 4,A 2 18 DIMENSION B 4 7 21 DIMENSION C I 10 23 DIMENSION C 10,1J 25 DIMENSION D -65535 1 26 DIMENSION D 65536 31 DIMENSION D 4 3 37 DIMENSION D A 2 4 38 DIMENSION D . 4 Эти классы эквивалентности покрываются 18 тестами. Читатель может при желании сравнить данные тесты с набором тестов, полученным каким-либо специальным
методом. Хотя эквивалентное разбиение значительно лучше случайного выбора тестов, оно все же имеет недостатки т.е. пропускает определенные типы высокоэффективных тестов . Анализ граничных значений и использование функциональных диаграмм - свободны от многих недостатков, присущих эквивалентному разбиению. Входные условия Правильные классы эквивалентности Неправильные классы эквивалентности
Число описателей массивов Один 1 , одного 2 Ни одного 3 Длина имени массива 1-6 4 0 5 , 6 6 Имя массива Имеет в своем составе буквы 7 и цифры 8 Содержит что-то еще 9 Имя массива начинается с буквы Да 10 Нет 11 Число индексов 1-7 12 0 13 , 7 14 Верхняя граница Константа 15 , целая переменная 16 Имя элемента массива 17 , что-то иное 18
Имя целой переменной Имеет в своем составе буквы 19 , и цифры 20 Состоит из чего-то еще 21 Целая переменная начинается с буквы Да 22 Нет 23 Константа -65534-65535 24 -65534 25 , 65535 26 Нижняя граница определена Да 27 , нет 28 Верхняя граница по отношению к нижней границе Больше 29 , равна 30 Меньше 31 Значение нижней границы
Отрицательное 32 , нуль 33 , 0 34 Нижняя граница Константа 35 , целая переменная 36 Имя элемента массива 37 , что-то иное 38 Оператор расположен на нескольких строках Да 39 , нет 40 2.3 Спецификация программы. Спецификация переменных. Название задачи Вычисление Название программы Functions Компьютер IBM PC 286 и выше Программное обеспечение
Turbo Pascal 7.0. Идентификатор переменных Назначение Тип данных Диапазон a,b,dx,x,f1,f2,f3 a - начало диапазона b - конец диапазона dx - шаг x - аргумент функции f1,f2,f3 - значения функций real 2,9 10-39 1,7 1038 2.4 Алгоритм программы и его описание. Блок - схема алгоритма приведена а Приложении 1 лист 001,002,003. Блок 1 - Описание переменных.
Блок 2,8,14 - Присвоение переменным значений. Блок 3,9,15 - Проверка условия. Блок 4,10,16 - Расчет функции. Блок 5,11,17 - Изменение х с шагом. Блок 6,7,12,13,18,19 - Вывод расчетов на экран. 2.5 Описание программы. Текст программы смотри Приложение 2. 1 - Название программы. 2 - Подключение модуля очистки экрана.
3,4,5 - Блок объявления переменных. 6 - Пустая строка. 7 - Объявление процедуры. 8 - Начало процедуры. 9,10 - Присвоение значений переменным. 11 - Проверка условия. 12 - Расчет функции. 13 - Вывод на экран. 14 - Изменение шага. 15 - Конец цикла. 16 - Вывод пустой строки на экран.
17 - Конец процедуры. 18 - Пустая строка. 19 - Объявление процедуры. 20 - Начало процедуры. 21,22 - Присвоение значений переменным. 23 - Проверка условия. 24 - Расчет функции. 25 - Вывод на экран. 26 - Изменение шага. 27 - Конец цикла. 28 - Вывод пустой строки на экран. 29 - Конец процедуры. 30 - Пустая строка. 31 - Объявление процедуры.
32 - Начало процедуры. 33,34 - Присвоение значений переменным. 35 - Проверка условия. 36 - Расчет функции. 37 - Вывод на экран. 38 - Изменение шага. 39 - Конец цикла. 40 - Вывод пустой строки на экран. 41 - Конец процедуры. 42 - Пустая строка. 43 - Начало основной программы. 44 - Очистка экрана. 45,46,47 - Запрос процедуры. 48 -
Ожидание нажатия клавиши для просмотра результатов. 49 - Конец программы. 2.6 Тестирование программы. Разработанная программа была оттестирована по методу эквивалентных разбиений. Входные условия Правильные классы эквивалентности Неправильные классы эквивалентности Границы диапазона 2,9 10-39 до 1,7 1038 1 2,9 10-39 2 ,
1,7 1038 3 Верхняя граница Константа 4 , вещественная переменная 5 Что-то иное 6 Имя вещественной переменной начинается с буквы Да 7 , Нет 8 Что-то иное 9 Нижняя граница определена Да 10 , нет 11 Верхняя граница по отношению к нижней границе Больше 12 , равно 13 Меньше 14 Нижняя граница Константа 15 , вещественная переменная 16
Что-то иное 17 Шаг изменения диапазона границы Константа 18 , единица 19 Что-то иное 20 Неправильные классы эквивалентности и соответствующие им тесты 2 a 3,0 10-39 3 b 1,8 1038 6 a t 9 x real 14 a 2.0 b 1.0 17 k integer 20 dx p 2.7 Контрольный пример. Входные данные a 0.0 b 1.0 dx 0.1 Выходные данные x 0.00 f1 0.00 x 0.10 f1 0.01 x 0.20 f1 0.04 x 0.30 f1 0.09 x 0.40 f1 0.16 x 0.50 f1 0.24
x 0.60 f1 0.34 x 0.70 f1 0.45 x 0.80 f1 0.57 x 0.90 f1 0.70 Входные данные a 0.5 b 2.1 dx 0.1 Выходные данные x 0.50 f2 0.44 x 0.70 f2 0.54 x 0.90 f2 0.56 x 1.10 f2 0.50 x 1.30 f2 0.35 x 1.50 f2 0.11 x 1.70 f2 -0.22 x 1.90 f2 -0.61 Входные данные a 2.0 b 4.75 dx 0.25 Выходные данные x 2.00 f3 1.41 x 2.25 f3 1.50 x 2.50 f3 1.58 x 2.75 f3 1.66 x 3.00 f3 1.73 x 3.25 f3 1.80 x 3.50 f3 1.87 x 3.75 f3 1.94 x 4.00 f3 2.00 x 4.25 f3 2.06 x 4.50
f3 2.12 x 4.75 f3 2.18 2.8 Инструкция пользователю. Программа предоставляется в виде исходного текста .pas . Для того чтобы программа работала в среде Паскаль, ее необходимо откомпилировать. Это делается следующим образом 1. Необходимо нажать следующее сочетание клавиш ALT F9, CTRL F9 2. После того, как программа выдаст результат, для того чтобы вернуться в режим исходного
текста необходимо нажать любую клавишу. 3. При необходимости рассчитать другой диапазон с другим шагом, необходимо изменить значения переменных a, b, dx в функциях fun1, fun2, fun3. Затем сохранить программу нажав клавишу F2. Далее смотри пункт 1,2. Заключение В данном отчете я постаралась отразить все стадии разработки программного продукта. Он очень трудоемкий и включает в себя множество этапов и полностью соответствует заданным требованиям.
В процессе прохождения практики, я ознакомилась с подробным процессом проектирования программного продукта. Особенно подробно был рассмотрен этап оформления документов, которые должны соответствовать ГОСТу и ЕСПД. Список использованной литературы 1. Г. Майерс Искусство тестирования программ 1982 г. 2. Б.В. Архангельский Поиск устойчивых ошибок в программах 1989 г.
3. В. Г. Мануйлов Разработка программного обеспечения на Паскале , 1998г. 4. В.В. Липаев Проектирование программных средств , 1990г. 5. Гласс Р. Руководство по надежному программированию , 1982г. 6. Зелковиц М Шоу А. Принципы разработки программного обеспечения , 1982г. 7. Боэм, Барри У. Инженерное проектирование программного обеспечения ,
1985г. Структура предприятия МУЗ ОМСЧ Севрыба . Приложение 1Лист 001 Лист 002 001 8 Лист 003 002 14 Приложение 2 program Functions 1 uses crt 2 var 3 a,b,dx,x real 4 f1,f2,f3 real 5 6 procedure fun1 7 begin 8 a 0.0 b 1.0 dx 0.1 9 x a 10 while x a and x b do begin 11 f1 x sin x 12 writeln x ,x, f1 ,f1 13 x x dx 14 end 15 writeln 16 end 17 18 procedure fun2 19 begin 20 a 0.5 b 2.1 dx 0.2 21 x a 22 while x a and x b do begin 23
f2 x cos x 24 writeln x ,x, f2 ,f2 25 x x dx 26 end 27 writeln 28 end 29 30 procedure fun3 31 begin 32 a 2.0 b 4.75 dx 0.25 33 x a 34 while x a and x b do begin 35 f3 sqrt x 36 writeln x ,x, f3 ,f3 37 x x dx 38 end 39 writeln 40 end 41 42 begin 43 clrscr 44 fun1 45 fun2 46 fun3 47 readkey 48 end. 49
| ! |
Как писать рефераты Практические рекомендации по написанию студенческих рефератов. |
| ! | План реферата Краткий список разделов, отражающий структура и порядок работы над будующим рефератом. |
| ! | Введение реферата Вводная часть работы, в которой отражается цель и обозначается список задач. |
| ! | Заключение реферата В заключении подводятся итоги, описывается была ли достигнута поставленная цель, каковы результаты. |
| ! | Оформление рефератов Методические рекомендации по грамотному оформлению работы по ГОСТ. |
| → | Виды рефератов Какими бывают рефераты по своему назначению и структуре. |