Введение в историю программного обеспечения Программное обеспечение играет ключевую роль в современном мире, обеспечивая работу компьютеров и различных устройств. Понимание его истории помогает лучше осознать, как технологии развивались и куда они могут двигаться в будущем. В этой статье мы рассмотрим основные этапы развития программного обеспечения, начиная с первых компьютеров и заканчивая современными тенденциями. История программного обеспечения — это не просто последовательность событий, а целая эволюция идей и технологий, которые изменили наш мир. Ранние этапы: от первых компьютеров до 1960-х годов Первые компьютеры и программирование В начале XX века компьютеры были механическими устройствами, которые использовались для выполнения математических расчетов. Одним из первых таких устройств был аналитический двигатель Чарльза Бэббиджа. Этот проект, хотя и не был завершен при жизни Бэббиджа, заложил основы для будущих вычислительных машин. Однако, настоящим прорывом стало появление электронных компьютеров в 1940-х годах. Эти машины, такие как ENIAC, использовали электронные компоненты, что значительно увеличило их скорость и мощность. ЭНИАК и первые программы ЭНИАК (ENIAC) был одним из первых электронных компьютеров, созданных в 1945 году. Он использовал перфокарты для ввода данных и программ. Программы для ЭНИАКа писались вручную на машинном языке, что было сложным и трудоемким процессом. Этот компьютер мог выполнять сложные математические расчеты, которые ранее занимали бы недели или месяцы, за считанные часы. Несмотря на свои ограничения, ЭНИАК стал важным шагом в развитии вычислительной техники. Появление ассемблера В 1950-х годах появились первые ассемблеры, которые позволяли программистам писать код на более удобном языке, чем машинный. Ассемблеры преобразовывали этот код в машинный язык, что значительно упростило процесс программирования. Это позволило создавать более сложные и эффективные программы, а также уменьшило количество ошибок. Ассемблеры стали важным инструментом для программистов, открыв новые возможности для разработки программного обеспечения. Эра мейнфреймов и мини-компьютеров: 1960-е – 1980-е годы Развитие мейнфреймов В 1960-х годах началась эра мейнфреймов — больших и мощных компьютеров, которые использовались в крупных организациях и правительственных учреждениях. Одним из самых известных мейнфреймов того времени был IBM System/360. Эти машины требовали сложного программного обеспечения для управления ресурсами и выполнения задач. Мейнфреймы стали основой для многих бизнес-приложений и научных исследований, обеспечивая высокую производительность и надежность. Появление операционных систем С развитием мейнфреймов возникла необходимость в операционных системах (ОС), которые могли бы управлять аппаратными ресурсами и выполнять программы. Одной из первых ОС была CTSS (Compatible Time-Sharing System), разработанная в MIT в 1961 году. В 1969 году появилась UNIX, которая стала основой для многих современных операционных систем. ОС позволили более эффективно использовать ресурсы компьютеров и упростили процесс разработки программного обеспечения. Мини-компьютеры и их влияние В 1970-х годах появились мини-компьютеры, такие как PDP-11 от Digital Equipment Corporation (DEC). Эти машины были менее мощными, но более доступными по цене, что позволило использовать их в малых и средних предприятиях. Программное обеспечение для миникомпьютеров также стало более доступным и разнообразным. Мини-компьютеры открыли новые возможности для автоматизации бизнес-процессов и научных исследований, став важным этапом в развитии вычислительной техники. Появление персональных компьютеров и операционных систем: 1980-е – 1990-е годы Революция персональных компьютеров В 1980-х годах началась революция персональных компьютеров (ПК). Одним из первых массовых ПК был IBM PC, выпущенный в 1981 году. Этот компьютер использовал операционную систему MS-DOS, разработанную Microsoft. ПК стали доступными для широкого круга пользователей, что привело к бурному развитию программного обеспечения. Персональные компьютеры изменили способ работы и общения людей, став неотъемлемой частью повседневной жизни. Развитие графических интерфейсов В середине 1980-х годов появились первые графические интерфейсы пользователя (GUI). Одной из первых ОС с GUI была Apple Macintosh, выпущенная в 1984 году. В 1985 году Microsoft выпустила Windows 1.0, которая со временем стала одной из самых популярных операционных систем в мире. Графические интерфейсы сделали компьютеры более доступными и удобными для обычных пользователей, открыв новые возможности для взаимодействия с техникой. Программное обеспечение для бизнеса и развлечений С развитием ПК появилось множество программ для различных целей. Программное обеспечение для бизнеса, такое как текстовые редакторы, электронные таблицы и базы данных, стало незаменимым инструментом для офисных работников. В то же время, индустрия видеоигр начала стремительно развиваться, предлагая пользователям все более сложные и увлекательные игры. ПК стали платформой для множества инноваций, изменивших различные аспекты жизни и работы. Современные тенденции и будущее программного обеспечения Облачные технологии и SaaS В последние годы облачные технологии и модели программного обеспечения как услуги (SaaS) стали доминирующими в индустрии. Облачные сервисы, такие как Amazon Web Services (AWS) и Microsoft Azure, позволяют компаниям хранить данные и запускать приложения на удаленных серверах, что снижает затраты на инфраструктуру и упрощает масштабирование. Облачные технологии изменили способ разработки и использования программного обеспечения, предоставляя новые возможности для бизнеса и пользователей. Искусственный интеллект и машинное обучение Искусственный интеллект (ИИ) и машинное обучение (МО) стали важными направлениями в разработке программного обеспечения. Эти технологии используются в различных областях, от автоматизации бизнес-процессов до создания интеллектуальных помощников, таких как Siri и Alexa. ИИ и МО открывают новые горизонты для разработки программного обеспечения, позволяя создавать более умные и адаптивные системы. Интернет вещей (IoT) Интернет вещей (IoT) — это концепция, предполагающая подключение различных устройств к интернету для обмена данными и управления. Программное обеспечение для IoT позволяет создавать умные дома, умные города и умные предприятия, улучшая качество жизни и повышая эффективность. IoT открывает новые возможности для автоматизации и оптимизации различных процессов, от управления энергопотреблением до мониторинга здоровья. Кибербезопасность С развитием технологий возрастает и угроза кибератак. Кибербезопасность стала одной из ключевых областей в разработке программного обеспечения. Современные решения включают антивирусные программы, системы обнаружения вторжений и средства защиты данных. Обеспечение безопасности данных и систем становится все более важным, особенно в условиях растущих угроз и сложных атак. Будущее программного обеспечения Будущее программного обеспечения обещает быть захватывающим и полным новых возможностей. Развитие квантовых компьютеров, виртуальной и дополненной реальности, а также биоинформатики открывает новые горизонты для разработчиков и пользователей. Важно продолжать изучать историю и следить за современными тенденциями, чтобы быть готовыми к вызовам и возможностям, которые принесет будущее. Технологии будут продолжать развиваться, предлагая новые инструменты и решения для различных сфер жизни и работы. Глава 1. Методология разработки и стандартизации 1.1. Особенности управления разработкой программ 1.1.1. Основные понятия и организация работ по разработке программных средств Современные сложные программные системы имеют ряд важных особенностей: наличие совокупности большого числа тесно взаимодействующих компонент различных типов (базовых классов, процедур, функций, ActiveX – элементов, COM/DCOM-компоненты и др.); иерархическую структуру связей компонент, обеспечивающую концептуальное единство и устойчивость функционирования всей системы; иерархическую совокупность критериев качества функционирования компонент и системы в целом; трудность формализации единого критерия качества и эффективности функционирования системы. разработка программных средств (ПС) содержит определенные этапы формализации, а переход от неформального представления о задаче к формальному существенно носит творческий характер, а не сводится к выполнению какой-либо последовательности формальных регламентированных действий (в этом смысле программирование можно отнести к искусству). Организация работ по проекту. Разработка сложных ПС проводится в рамках проекта, под которым понимается комплекс формально организованных мероприятий по созданию сложной системы с заданными характеристиками качества при ограниченных ресурсах. Управление проектом – это вид деятельности, включающей в себя постановку задач, подготовку решений, планирование, организацию и стимулирование специалистов, контроль за ходом выполнения работ и использованием ресурсов при создании сложных систем. Цель управления проектом – рациональное использование ресурсов путем сбалансированного распределения их по частным работам на протяжении всего цикла разработки. Целевое управление проектами возникло из необходимости разрабатывать и реализовывать сложные системы с заданными функциями в максимально короткие сроки. Критическим параметром планирования и управления проектами обычно является время. Далее основное внимание сосредоточено на конкретном планировании сложных проектов, периоды разработки, которых могут составлять несколько лет. Задача целевого управления – сводить воедино усилия прямых исполнителей, подрядчиков и субподрядчиков, добиваясь, чтобы они выступали как команда. В результате должны обеспечиваться концептуальная целостность системы и высокое качество решения главных задач при сбалансированном использовании ресурсов на все функциональные задачи. Для управления проектом, прежде всего, должен быть адекватно описан объект проектирования. Для сложных систем формализация описания и характеристик объекта разработки происходит одновременно с процессом его проектирования. Последовательно уточняются архитектура объекта, основные функции и их характеристики, требующиеся показатели качества функционирования и методы решения задач. Все эти данные отражаются в техническом задании (ТЗ), спецификации требований и описании проекта, которые детализируются и конкретизируются по мере развития проекта. Для реализации проекта назначается руководитель проекта (главный инженер (ГИП) или менеджер проекта), который отвечает за организацию взаимодействия с заказчиком, за оформление договоров и всех финансовых документов, за координацию работ и за проведение технической политики. В виду того, что руководитель проекта непосредственно общается с руководством заказчика, он должен быть человеком коммуникабельным, дипломатичным и корректным, настойчивым, уметь тактично отстаивать интересы разработчиков, уметь оформлять финансовые и технические документы, подписываемые заказчиком. Одновременно руководить проекта должен быть опытным и высокопрофессиональным проектировщиком, способным решать сложные различные технические проблемы, проводить техническую политику, организовывать и координировать работу многих специалистов и подразделений, участвующих в проекте. Существуют различные формы организации работ по проекту. В больших проектных организациях, например, может использоваться следующая организация. Подразделения специализируются по функциональным подсистемам (например, оперативное управление, логистика, планирование, сбыт, управление персоналом, материально-техническое снабжение, бухгалтерский учёт, управление качеством) и по видам обеспечения (например, информационное, техническое, общесистемное программное обеспечение, организационное). Специализация может быть и более крупная, например, по отраслям объектов автоматизации (промышленные, образование, медицина, транспорт, сельское хозяйство, муниципальные и федеральное органы управления). В этих специализированных подразделениях есть постановщики задач, программисты и другие специалисты. Все руководители проектов объединяются в один отдел, который подчиняется непосредственно главному инженеру или заместителю директора организации по проектированию. Через этот отдел проводится единая техническая политика проектной организации. Такая специализация позволяет более быстро и качественно разрабатывать проект за счет узкой специализации проектировщиков и программистов и использования типовых проектных решения, которые вырабатываются при работе над различными проектами по отдельным подсистемам. К недостаткам такой организации можно отнести децентрализацию разработки по нескольким подразделениям, что требует высокого уровня координации работ между подразделениями в рамках одного проекта и эта координация возложена на руководителя проекта, который должен иметь соответствующие полномочия, позволяющие вмешиваться в работу подразделений в рамках своего проекта. При разработке ПС могут использовать следующие основные технологии и комплексы средств автоматизации: методы и средства автоматизации системного анализа и проектирования; типизацию проектов систем; CASE-системы с использованием репозитариев данных о состоянии и развитии проектов; языки четвертого поколения; повторное использование готовых программных и информационных компонентов; графический интерфейс; стандарты управления проектированием, конфигурацией и обеспечением качества; сертификацию. Проектирование ПС – это процесс составления описания еще несуществующей системы на разных языках и с различной степенью детализации. Укрупнено, можно выделить следующие этапы проектирования: описание требований, архитектурное проектирование, обобщение спецификации, проектирование интерфейсов, компонентное проектирование, проектирование структур и алгоритмов. Результаты проектирования являются описание архитектуры системы, интерфейсов, структур данных, подсистем, компонентов, алгоритмов. Реализация ПС – процесс перевода описания ПС в работоспособную систему. Определяется: структура ПС, данные, интерфейсы взаимодействия системных компонентов и алгоритм. Перед проектированием и реализацией ПС следует выбрать соответствующие стандарты (обычно жизненного цикла ПС), которые регламентируют эти процессы. 1.1.2. Классы программ По внутренним свойствам каждую программу можно отнести к одному или к нескольким следующим видам программ: комплекс или система программ (КП) – это набор взаимосвязанных программ, реализующий некоторую крупную задачу пользователя; программное средство (ПС) – это программа или комплекс программ, предназначенная для автоматизации обработки данных, например, Word, Excel; программный продукт или изделие (ПП) – это программа или комплекс программ, предназначенный для продажи (предприятия, разрабатывающие программные продукты, приравниваются по статусу к промышленным предприятиям); программное обеспечение (ПО) – это комплекс программ, обеспечивающий функционирование другой, более главной системы, например, автоматизированной информационной системы, автоматизированного рабочего места (АРМ), технической системы (станков с программным управлением); пакет прикладных программ или средств (ППП) – это комплекс программ, имеющий средства настройки на конкретные условия применения. Например, пакет «1С – Бухгалтерия» является одновременно программной системой, программным средством обработки бухгалтерских данных, программным продуктом (продается и покупается), пакетом прикладных программ (имеет средство настройки конфигуратор). Классификация программ по областям применения: Продукция народного потребления, используемая вне прямой производственнотехнической и научно-исследовательской деятельности специалистов. Это программы, создаваемые преимущественно для персональных компьютеров, используемых в быту (курсы обучения, справочные сведения, пакеты для несложных научных и инженерных расчетов, игры и др.). Продукция научно-технического применения для решения инженерновычислительных и научно-исследовательских задач. Ряд программ этой категории имеет широкую область применения, может тиражироваться в тысячах экземпляров и поставляться вместе с эксплуатационной документацией. Продукция производственно-технического назначения, предназначенная для автоматизации труда в организациях и на предприятиях народного хозяйства. Программные средства этой категории можно разделить на три крупных класса: a) комплексы программ общесистемного назначения, обеспечивающие возможность выполнения компьютером основных функций (операционные системы и пакеты прикладных программ, расширяющие функциональные возможности операционных систем; диалоговые системы, обеспечивающие интерфейс различных видов пользователей с компьютером; системы управления базами данных; типовые проблемно - ориентированные инструментальные системы; программные системы обеспечения телекоммуникаций в типовых локальных и распределенных сетях компьютеров); b) системы обработки данных (информационно-справочные системы; автоматизированные системы организационного управления отраслями, организациями и предприятиями; системы автоматизированного проектирования промышленных изделий; системы автоматизации технологической подготовки производства; экспертные системы; системы обработки и редактирования текстовых документов; пакеты прикладных программ для решения типовых задач; c) программы систем управления объектами и процессами в реальном времени; автоматизированные системы управления технологическими процессами; гибкие производственные системы; станки с числовым программным управлением и промышленные роботы; системы управления движущимися и другими объектами; системы управления научными экспериментами и сложными приборами. Классификация программ по риску: Критические программы, от которых требуется особенно высокое качество надежного функционирования. Важные программы, которые также должны обладать особенно высоким качеством, и ущерб от ошибок в них может быть велик, но невозможны катастрофические последствия их проявления. Ординарные программы, которые являются наиболее массовыми и широко распространенными; их качество и области применения изменяются в широких пределах. 1.1.3. Архитектура программных средс тв Иерархическое построение сложных программ позволяет ограничить и локализовать на каждом из уровней соответствующие ему компоненты. Нижнему иерархическому уровню представления программ соответствуют программные* и информационные модули. Иерархическая структура программ имеет ряд специфических свойств: вертикальная соподчиненность, заключающаяся в последовательном упорядоченном расположении взаимодействующих компонентов; право вмешательства и приоритетного воздействия на компоненты любых уровней; взаимозависимость действий компонент верхних уровней от реакций на воздействия и от функционирования компонент нижних уровней, информация о которых передается верхним уровням. В результате в иерархических структурах ПС образуются два потока взаимодействий между компонентами разных уровней: сверху вниз – координирующие и управляющие воздействия верхних уровней; снизу вверх – информация о состоянии и реализации предписанных функций компонентами нижних уровней. Координация предполагает выбор способа координации и реализацию координирующих алгоритмов с выработкой соответствующих воздействий. Координируемые компоненты обычно имеют некоторую автономность поведения и подготовки локальных решений. Степень автономности компонентов и интенсивность координирующих воздействий устанавливаются в результате компромисса при выделении иерархических уровней. Взаимодействие компонентов в пределах уровня целесообразно максимально ограничивать, что позволит упростить общее координирование компонент и проводить его только по вертикали. Число уровней определяется объемом и сложностью ПС. С повышением иерархического уровня увеличиваются объем программ, реализующих компоненты каждого уровня, и количество обрабатываемых переменных. Одновременно совокупности команд все более специализируются, и снижается возможность повторного применения компонентов в различных комбинациях для решения аналогичных задач. Гибкость модификации и эффективность управления разработкой обеспечиваются за счет соблюдения ряда принципов и правил структурного построения ПС и его компонентов, а также взаимодействия между ними. Эти правила направлены на стандартизацию структуры, взаимодействия компонентов разного ранга и их назначения в пределах проблемной области. В результате системного анализа создаются стандартизированная структура программ определенного класса и система правил ее формирования. Эта структура базируется на принципах модульно-иерархического построения ПС, основными элементами которых являются модули. Программные модули могут объединяться в функционально законченные группы программ. В такой стандартизированной структуре целесообразно выделять функциональные модули, подверженные наибольшим изменениям, а также средства контроля и организации вычислительного процесса и типовые функции. Эти средства и функции обычно * Под программным модулем, или компонентом, понимаются процедура, функция, класс, ActiveX-элемент, COM/DCOM-компонент. связаны с особенностями реализующего компьютера и могут применяться в нескольких проблемно-ориентированных областях. Программные модули для их повторного использования должны базироваться на унифицированных правилах структурного построения, оформления спецификаций требований и описаний текстов. Эти правила в значительной степени стандартизированы в современных языках программирования высокого уровня. Целесообразно создавать дополнительные правила структурного построения модулей и выделять типовые ассоциации операторов и ограничения их использования, а также вводить правила описания текстов на языке программирования и комментариев, правила описания данных и заголовков модулей, ограничения размеров и их сложности и т. д. Правила стандартизации структуры межмодульного интерфейса по передачам управления и по информации формируются на базе описания языков программирования или оформляются на основе правил структурного построения программ. При разработке серии однотипных версий ПС для некоторой прикладной области целесообразно выбрать и унифицировать внешний интерфейс и операционную систему. Для эффективного управления разработкой программ необходимо стандартизировать и соблюдать ряд принципов и правил архитектурного построения ПС. 1.2. Стандартизация жизне нного цикла программных средств 1.2.1. Уровни стандартизации Одним из путей повышения эффективности создания ПС являются стандартизация и автоматизация технологических процессов проектирования, разработки и сопровождения программ для компьютера. В стандартах обобщаются опыт и результаты исследований множества специалистов и сосредоточиваются наиболее эффективные современные методы и процессы. Существуют следующие разновидности нормативных документов. Стандарт – это нормативно-технический документ, устанавливающий комплекс норм, правил и требований к объекту стандартизации, разработанный на основе согласия и на обобщенных результатах научных исследований, технических достижений и практического опыта, направленный на достижение оптимальной пользы для общества. Стандарты бывают двух типов: де–юре - официально принятые организацией по стандартизации (например, международный стандарт языка SQL). де–факто - добровольно принятые пользователями без формального принятия организацией по стандартизации. Назначение стандартов: - устанавливают параметры качества объекта стандартизации; - задают современные технологии производства и использования объектов стандартизации. - унифицируют объекты стандартизации, что позволяет собирать более сложные объекты, не зависимо где и кем были произведены объекты, например, детали, узлы, изделия, программные модули различных типов: базовые классы, ActiveX– элементы, COM/DCOM-компоненты, программные интерфейсы (например, связывание и встраивание объектов OLE), процедуры, функции, SQL-запросы и др. Унификация позволяет разработчикам программного обеспечения перейти от огромного множества разнообразных не связанных между собой разрозненных программных модулей к небольшому, хорошо интегрируемых набору программных модулей со стандартной структурой. Это, в частности, позволяет разрабатывать и использовать эти модули при разработке программного обеспечения на различных языках программирования; Базовый стандарт – это принятый нормативный документ, регламентирующий типовые (возможно многовариантные) требования, нормы и правила применительно к объекту стандартизации. Профиль стандарта – это принятый нормативный документ, регламентирующий требования, нормы и правила, выбранные из базового стандарта и, при необходимости, уточненные и/или пополненные применительно к конкретному объекту стандартизации. Предварительный стандарт – это временный документ, используемый для получения отзывов для решения вопроса о целесообразности принятия стандарта. Техническое условие (ТУ) – устанавливает технические требования к продукции, услуги или процессу с указанием методов и процедур проверки в соблюдении требований технических условий. Технические условия разрабатывают предприятия в том случае, когда стандарт предприятия создавать не целесообразно. Свод правил – содержит основные правила проектирования, монтажа, оборудования и конструкции, технического обслуживания и эксплуатации объектов, конструкций, изделий. Регламент – это документ, в котором содержатся обязательные правовые нормы. Положение – это документ, регламентирующий деятельность отдельного подразделения или организации в целом. Можно выделить следующие уровни стандартов. 1) Международные стандарты ISO/IEC, разрабатываемые Международной организацией стандартизации (International Standards Organization – ISO от греческого слова ISOS – равный, чтобы аббревиатура на всех языках была одинаковой) и Международной комиссией по электротехнике (International Electro-technical Commission – IEC). Международная организация по стандартизации – это всемирная организация, ответственная за разработку международных стандартов путем координации деятельности участвующих национальных органов стандартизации стран мира. На этом уровне осуществляется стандартизация наиболее общих технологических методов и процессов, имеющих значение для международной кооперации и разделения труда (прил. 1.1, 1.2, 1.3). Сфера деятельности ISO касается стандартизации во всех областях, кроме электротехники, электроники, радиосвязи и приборостроения, которыми занимается IEC. ИСО поддерживает связь с региональными организациями по стандартизации, например, с Европейским комитетом по стандартизации (CEH) и Европейской ассоциацией производителей вычислительных машин (ЕСМА, технический комитет ТК32 «Передача данных, сети и взаимосвязь систем»), созданной в 60-х гг. с целью координировать деятельность Европейских производственных средств обработки данных. Вопросами информационных технологий, микропроцессорной техники входят в область совместных разработок ИСО/МЭК, которые проводятся созданным в 1987 году Объединенным техническим комитетом JTC1 (Joint Technical Committee 1). В этом комитете существуют несколько подкомитетов и групп, которые специализируются по различным направлениям, например, разработка программного обеспечения и документации, языки программирования, компьютерная графика, телекоммуникация и информационный обмен, управлением данными, информационная безопасность, символьные данные и кодирование информации и др. Стандарты ISO/IEC имеют рекомендательный характер. Можно ещё отметить Международный союз электросвязи, Международный консультативный комитет по телеграфии и телефонии – занимается разработкой международных стандартов в области радио и связи, телефонии, телеграфии, передачи данных, программ звукового и TV вещания, мультимедийных служб. В частности на международном уровне решаются проблемы информационной совместимости различных архитектур. Разработана общая базовая эталонная модель - стандарт ИСО 7498 – все многочисленные функции сети были разделены на группы, каждая группа функций была отделена от другой стандартными интерфейсами и получила относительную независимость. Открытые системы – используют стандарт между однородными аппаратными компонентами. Для взаимосвязи открытых систем в федеральных правительственных службах возникли правительственные профили взаимосвязи открытых систем (Government Open Interconnection Profile - GOSIP), которые определяют и описывают общую совместимость протоколов обмена данными, которые позволяют системам, разработанными различными поставщиками взаимодействовать между собой, а пользователям этих систем обмениваться информацией. 2) Американские национальные стандарты в виду лидирующих позиций США в Мировой экономике и информатике, имеют оттенок международных стандартов. Во многих случаях они служат базой для последующего создания стандартов уровня ISO/IEC. Единственной организацией в США, которая утверждает стандарты, является Национальный институт стандартов и технологий (NIST), бывший Американский национальный институт стандартов (ANSI). Разрабатывают федеральные стандарты организации, аккредитованные NIST. В области электротехники и электроники стандарты разрабатываются Институтом инженеров электротехники и радиоэлектроники США (Institute of Electromechanical and Electronics Engineers – IEEE). По этому направлению разработано наибольшее число стандартов в рассматриваемой области (прил. 1.2, 1.3). Стандарты NIST/IEEE в основном имеют рекомендательный характер, кроме, требований, касающихся безопасности. Для министерства обороны США есть отдельные группы стандартов (MIL, DOD), которые имеют повышенные требования к качеству, надежности и безопасности и являются обязательными для фирм, работающих по заказам этого министерства обороны. 3) Национальные стандарты отдельных государств. Для России это ГОСТ (прил. 1.4 – 1.7, http://standards.narod.ru). В России деятельность по стандартизации регулируется законом РФ «О стандартизации», а национальным органом по стандартизации является Государственный комитет Российской Федерации по стандартизации и метрологии (Госстандарт России), который имеет свой логотип. В его ведении находятся службы по надзору за государственными стандартами и обеспечением единства измерений, более 100 центров стандартизации, метрологии и сертификации (ЦСМ), 19 научно-исследовательских институтов, 13 опытных заводов, 2 типографии, 3 учебных заведения. Постоянными рабочими органами являются технические комитеты, которые специализируются по объектам стандартизации. Все стандарты, разработанные в России, разбиты на группы, и их кодовое обозначение имеет следующий вид: ГОСТ ГГ.ТNN – ХХ, где ГГ – числовой номер группы стандартов; Т – числовой тип стандарта; NN – числовой номер стандарта данного типа; ХХ – две последние цифры номера года издания стандарта. Основные группы стандартов в области информатики: ГОСТ 19 - ЕСПД (Единая система программы документации); ГОСТ 24 - АСУ (Автоматизированная система управления); ГОСТ 34 - АС (Автоматизированная система). Большинство этих стандартов морально устарели. Обновление стандартов происходит в основном путем включения соответствующих международных стандартов в состав Российских вместо устаревших или в качестве новых стандартов. Такие стандарты обозначаются в виде: ГОСТ Р ИСО/МЭК NNNNNNNN-XX, где NN – номер стандарта по международной классификации; ХХ – две последние цифры номера года принятия стандарта в состав Российских стандартов (номер года не всегда указывается). Все стандарты в России являются необязательными. Причиной этого является возможность выпуска новых изделий, товаров и предоставления услуг при отсутствии соответствующих стандартов (исключается прохождение долговременных бюрократических процедур разработки и утверждения новых стандартов), что расширяет номенклатуру изделий, товаров и услуг. Стандарты становятся обязательными на контрактной (договорной) или на добровольной основах. Поэтому, если заказчик или разработчик проекта желают вести разработку и оформление документации по определенным стандартам, то нужно указать необходимость их использования в техническом задании на проект. 4) Отраслевые стандарты (ОСТ) отражают специфику отрасли, и они детализируют государственные стандарты или восполняют их отсутствие, но в любом случае они не должны противоречить государственным стандартам. Обычно они обозначаются в виде: OCT XXXXXXXX, где XXXXXXXX – номер отраслевого стандарта. Степень обязательности соблюдения таких стандартов определяется предприятием, которое применяет его или по договору между изготовителем и потребителем. Контроль за выполнением стандарта организует организация, принявшая этот стандарт. 5) Стандарты предприятий (СТП) (внутрифирменные или внутрикорпоративные стандарты) отражают специфику предприятия, они детализируют государственные или отраслевые стандарты или восполняют их отсутствие и не должны противоречить государственным и отраслевым стандартам. Обычно они обозначаются в виде: СТП XXXXXXXX, где XXXXXXXX – номер стандарта. Стандарты предприятия основываются на применении передовых технологий, получивших наибольшее распространение в области разработки программного обеспечения, являются обязательными и вводятся в действие приказом руководителя предприятия, в котором указывается срок и область действия стандарта, способы доведения до исполнителей, ответственные лица за контролем исполнения и ответственность за не выполнение требования стандарта (например, лишении премии). Если на предприятии имеется подразделение нормоконтроля, то стандарт предприятия передается в это подразделение для контроля соблюдения требований стандартов при разработке и документировании проектов. Для разработки таких стандартов привлекаются ведущие специалисты (владеющие методами средствами организации и разработки ПС) из различных заинтересованных подразделений разработчика и пользователя (например, при разработке стандарта на пользовательский интерфейс). Стандарты должны оперативно пересматриваться, иначе они могут тормозить процессы ввода в производство современных технологий и снижать качество выпускаемой продукции. Стандарты предприятия можно разделить на две группы: 1) производственные – регламентируют процессы разработки проекта по стадиям и этапам жизненного цикла программного средства; 2) управленческие – регламентируют порядок управления разработкой проектов. Хорошо разработанные стандарты предприятия способствуют повышению качества, надежности, удобства использования и унификации разрабатываемого ПС. Стандарт предприятия должен содержать следующий компоненты: назначение, область применения, термины и сокращения, ответственность, срок действия, описание методики, указания и примечания, порядок разработки и предоставления пользователем, порядок внесения изменений, приложения. Часто стандарт предприятия разрабатывается путем детализации соответствующего государственного или отраслевого стандарта (т.е. является профилем соответствующего вышестоящего стандарта), например, руководства программиста, системного программиста и пользователя из группы государственных стандартов ГОСТ 19 (ЕСПД). В идеале, СТП должны охватывать все технологические и другие операции и процессы в предприятии и должны быть обязательными для всех сотрудников предприятия, причем, сотрудники не обязаны знать вышестоящие стандарты, если они положены в основу разработанных СТП. Разработка СТП должна проводится с привлечением будущих пользователей СТП под руководством руководителя предприятия в следующей последовательности: формирование оглавления, определение типовых форм, назначение исполнителей и ответственных, разработка календарного графика, описание входных и выходных данных, составление глоссария терминов. Приведем следующие наиболее общепринятые СТП в области разработки ПС: анализ и проектирование. Общие стандарты, регламентируют правила общения с клиентами и сотрудниками; перечень используемого программного обеспечения; способы обмена данными между программами, организации хранения программ и др. Стандарты анализа и проектирования регламентируют применение методик (структурного, объектно-ориентированного) и средств (BPWin, ERWin, Rational Rose и др.) анализа предметной области; правила оформления и хранения аналитической информации, наименований файлов и других объектов. Стандарты разработки регламентируют формирование полных и наименований и сокращенных наименований различных объектов (файлов, программ, процедур, версий, директорий, баз данных и др.), отладку, использование команд языка программирования и структурного программирования, формирование интерфейса пользователя (принципы разработки интерфейса), сообщений пользователю (например, использования отдельного файла с текстом сообщений), проектирования баз данных, порядок ведений версий и др. Стандарты тестирования определяют методику тестирования, регламентируют порядок проведения тестирования, оценку и оформление результатов. 1.2.2. Основные модели кла жизненного ци Модель жизненного цикла ПС (ЖЦ ПС) – структура, содержащая процессы, действия и задачи, которые осуществляются в ходе разработки, функционирования и сопровождения программного средства в течение всей жизни системы, от определения требований до завершения ее использования (прил. 1.1). В самом общем виде ЖСПС включает этапы системного анализа, проектирования, эксплуатация и сопровождение ПС. В стандартах, регламентирующих ЖС ПС, обобщаются опыт и результаты исследований, рекомендуются наиболее эффективные методы и процессы проектирования, разработки, тестирования, внедрения и эксплуатации ПС. Примеры стандартов ЖЦ ПС: ISO/IEC 12207 (ГОСТ Р ИСО/МЭК 12207) – современный международный стандарт (прил. 1.1); MIL-STD-498 – разработка и документирование программного обеспечения. Этот стандарт базируется на стандарте ISO/IEC 12207 и предшествующих военных стандартах (DOD-STD2167 A, 7935 A, 1703). ГОСТ 19.102-77 ЕСПД (прил. 1.5); ГОСТ 34.601-90 (прил. 1.7). 1.2.2.1. Каскадная модель Модель предполагает последовательное выполнение этапов. Достоинства: возможность планирования сроков и затрат, формирование на каждом этапе технической документации, что создает комфортную среду разработчику, т.к. все проблемы решены на предыдущих этапах. Например, на предыдущем этапе проектирования разработаны и согласованы с заказчиком постановка задачи с алгоритмом ее решения и формами входных и выходных документов, структурой базы данных и программисту на следующем этапе рабочего проектирования нужно только по готовой постановке задачи нужно только разработать программное обеспечение. Недостаток: отсутствие возможности пересмотра отдельных уже пройденных этапов и удлинение сроков разработки (например, задержка в проектировании одной или нескольких задач не дает возможность начать программирование уже готовых для этого задач). Данную модель удобно применять тогда, когда требования могут быть формализованы четко и корректно. 1.2.2.2. Каскадная модель с промежуточным контролем Модель аналогична предыдущей модели, но по окончании каждого этапа производится его оценка, и при неудовлетворительной оценке производится возвращение на соответствующий предыдущий этап для перепроектирования. Достоинство: большая надежность ПС. Недостаток: увеличение периода разработки. 1.2.2.3. Модель разработки программных средств на основе ранее созданных компонентов Модель предполагает, что отдельные составные части программы уже существуют. Основное внимание уделяется модификации и разработке при необходимости новых компонентов и интеграции отдельных компонентов в общее целое. Достоинство – сокращение сроков разработки. Недостатки – необходимость адаптации и не все требованию пользователей могут быть учтены. Используется при наличии соответствующего пакета прикладных программ или исходных текстов программ. 1.2.2.4. Эволюционная модель Разрабатывается первоначальная версия ПС, которая затем сразу же передается на испытание пользователю, затем она дорабатывается с учетом мнения пользователя. Удобно применять, когда заказчик четко не может сформулировать свои требования или меняет их в процессе создания ПС. Достоинство - спецификация может разрабатываться постепенно, по мере того, как заказчик осознает, что ему нужно. Недостатки – плохая документированность и структурируемость ПС; перепрограммирование кода ПС. Используется при разработки небольших ПС. 1.2.2.5. Модель пошаговой разработки программных средств Модель занимает промежуточное положение между каскадной и эволюционной моделями. В её рамках разработчик вначале определяет функции ПС в самых общих чертах, устанавливают приоритеты и определяют количество этапов (очередей или версий). Каждый этап должен быть результирующим. Достоинства - заказчику не нужно ждать полного завершения разработки; заказчик может использовать компоненты системы, которые получены на первых шагах как прототипы; уменьшение риска общих системных ошибок; наиболее важные подсистемы подвергаются более тщательному тестированию и проверке. Недостатки - сложность отображения системных требований и компонентов больших размеров и распределения общих системных функций по компонентам. 1.2.2.6. Спиральная модель Эта модель устраняет недостатки каскадных моделей. На каждом витке этапы модели могут уточняться или дополняться новыми работами (рисунок 1.2.2.6.1). Каждый виток дает уточненную работоспособную версию ПС, которую можно предъявлять пользователю для оценки. Первая версия может быть ограниченная по своим возможностям, не эффективная, но он реализована в короткие сроки, функционирует и уже дает результаты пользователю, по которым можно выявить недостатки и ошибки в работе и устранить их в следующей версии. После принятия решения о начале разработки новой версии ПС, следует произвести: определение целей, ограничений на процесс создания, уточнение плана разработки, определение проектных рисков, определение проектного риска и его уменьшение, разработку тестов. Недостатки - увеличение суммарной трудоемкости разработки (за счет переписывания фрагментов программного кода при разработке новой версии) и соблюдения требования совместимости с предыдущими версиями, что приводит к невозможности реализации разработчиком максимально лучшего варианта, к необходимости сохранения кода предыдущих версии и к дополнительному кодированию, что усложняет программу и снижает эффективность выполнения новой версии ПС. Эскизное проектирование Техническое проектирование Техническое задание 1 Рабочее проектирование 2 3 Функционирование и сопровождение Внедрение версий Рисунок 1.2.2.6.1. Этапы спиральной модели ЖЦ ПС 1.2.2.7. Спиральная модель с ограничением версий Модель аналогична предыдущей модели, но число версий ограничивается. Таким образом, если разработчик находит кардинально лучшее решение, приводящие к нарушению совместимости с предыдущими версиями, и/или предполагаемая новая версия практически существенно не улучшает ПС, то принимается решение о прекращении дальнейшей разработки. Таким образом, последний недостаток предыдущий модели устраняется на некоторой версии ПС. 1.2.3. Структурное программирование Структурное программирование – это программирование в соответствии с заранее определенным набором правил и принципов, облегчающих восприятие и отладку программ, повышающих их надежность, гибкость и эффективность. Принципы структурного программирования 1. Модульное программирование – процесс разбиения программы на отдельные программные модули (базовые классы, процедуры, функции, ActiveX – элементы, COM/DCOM-компоненты и др.). Свойства модуля: возникает в результате отдельной компиляции; вызывается по имени; возвращает управление тому, кто его вызывал; может обращаться к другим модулям, непосредственно нижестоящим в схеме иерархии; должен быть небольшого размера; должен иметь один вход и один выход; не должен сохранять историю вызовов для управления своим функционированием; обладает единственной функцией; должен быть независимым от других модулей; должен содержать тесно связанные элементы; должен проверять аргументы; при возникновении в модуле ошибок управление должно возвращаться обратно; должен быть замкнутым. 2. Проектирование и кодирование (программирование) сверху вниз. Если проект большой, то он разбивается на части, представляющие собой древовидную структуру (схема иерархии). Сначала задача описывается на естественном языке, в дальнейшем проект постепенно уточняется, и на каждом шаге выявляются детальные функции. Таким образом, задача разбивается на подзадачи до тех пор, пока они не станут настолько простыми, что каждой из них будет соответствовать один программный модуль. Достоинства: хорошая комплексная отладка; заказчик участвует в проектировании; промежуточные результаты можно показать заказчику. Недостатки: слабая автономная отладка модулей; наличие программ-заглушек, которые имитируют работу несуществующих программ нижнего уровня. Обычно для больших проектов применяется метод «сэндвича». Для одних частей используется метод нисходящего, а для других – метод восходящего проектирования. 3. Защитное программирование. Это такой стиль написания программ, при котором появляющиеся ошибки легко обнаруживаются и идентифицируются программистом. Средства защитного программирования: все входные данные или действия пользователя подлежат обязательной проверке (принцип «всеобщего недоверия»); немедленное обнаружение ошибок; изолирование и минимизация последствий ошибок. Для предотвращения ошибок в программе рекомендуется не применять непроверенные способы программирования. Не используйте принцип умолчания значений (когда при отсутствии параметра программа принимает его определенное значение), так как они могут изменяться в новых версиях. Не допускайте зависимости программ от недостоверности данных. Стремитесь минимизировать число обращений к пользователю. Тестирование – процесс обнаружения ошибок программы. Тестовые примеры разрабатываются постановщиком на этапе разработки алгоритма. Обычно вместо одного теста готовится целая серия тестов. Рекомендуется тестирование сверху вниз. Первый тест должен быть простым, так как он показывает работу программы вообще. Следующие тесты, предназначенные для проверки общей организации программы, обеспечивают обнаружение грубых ошибок. Повторно тестируйте исправленный код. Ведите журнал обнаруженных ошибок и изменений программы. Этапы тестирования: Проверка в нормальных условиях для характерной совокупности допустимых значений. Проверка в экстремальных условиях в приграничных областях допустимых значений (граничные допустимые значения, нулевые данные, пустые циклы, массивы, файлы). Проверка в исключительных ситуациях в областях недопустимых значений. С целью выявления ошибок организуется сквозной структурный контроль (просмотр). В этом случае собираются 4–6 специалистов, которые получают необходимые материалы за 5–7 дней до начала совещания. Время совещания ограничивается двумя часами. Ведущий совещание обеспечивает составление полного списка обнаруженных ошибок. В начале совещания эксперты характеризуют степень завершенности и качество проекта. Разработчик делает обзор проделанной работы, результаты подвергаются групповому анализу. По окончании совещания председатель вручает каждому участнику список ошибок и проблем, требующих решения. Разработчик обязан устранить ошибки и сообщить об этом эксперту. 4. Наглядность исходных текстов программ. Стиль программирования, который позволяет получать удобные для применения и легко читаемые программы. Стиль связан с удобочитаемостью программы. Рекомендации. Вводный комментарий объясняет назначение и условия применения. Пояснительные комментарии сопровождают те части программы, которые трудно понять. Дополнительные пробелы указываются повсюду, где это приводит к улучшению читабельности программы. Переменные следует явно объявлять и комментировать. Имена должны отображать смысл содержания. Допускается префиксная нотация (перед именем объекта), которая отражает тип объекта (cmdVixod – имя командной кнопки «Выход»). Составные имена следует писать через знак подчеркивания или начинать с прописных букв. Используйте общепринятые имена, которые описывают действия. В сокращения наименований полей, переменных и других программных объектов всегда должны входить начальные буквы. Согласные важнее гласных. Начало слова важнее его конца. Списки имен в командах объявления упорядочиваются по алфавиту. Используйте общепринятые сокращения. При записи операторов и для указания связи между ними делаются одинаковые отступы от начала строки в размере трех позиций, т.е. отступами выделяются структуры вложенности отдельных фрагментов программы. 5. Гибкость и эффективность программ. Выносите изменяемые константы, адреса и имена файлов, баз данных в отдельные файлы настройки. Оптимизируйте программу после ее отладки. Используйте именованные константы вместо обычных. Минимизируйте применение глобальных переменных, вложенных структур и команд перехода Goto. Ограничивайте действия над параметрами подпрограмм (например, для Visual Basic – ByVal, ByRef; для Pascal – Optional, Var, Out, Const). Общие рекомендации программисту. Помните: программы читаются людьми, и поэтому их тексты должны быть легко читаемыми и понятными. Используйте вводные комментарии. Располагайте комментарии в программе таким образом, чтобы это не делало ее менее наглядной. Одного оператора в строке достаточно. Для выделения структуры используйте отступы (начало и конец структуры сдвинуты на три позиции влево относительно тела структуры). Фиксируйте соответствие букв кириллицы и букв латинского алфавита (например, Щ (H), И (I), B (V)). Стремитесь к простоте и универсальности (например, программа имеет средства настройки на форматы и значения данных). Используйте постоянные приемы программирования. Унифицируйте форматы ввода и вывода информации. Обеспечивайте максимально удобный интерфейс пользователю. Интересуйтесь, как эксплуатируется программа (поработайте со своей программой в качестве пользователя). Устанавливайте более скромные цели (работающие программы гораздо полезнее и важнее незаконченных громадных проектов). Общая схема упрощения – разбиение программы на модули и оформление каждого модуля в виде процедуры, функции, класса, ActiveX-элемента, компонента. Сложность возрастает квадратично размеру программы. Рекомендуется заменять циклы или вложенные конструкции на функции.
