Добавлен: 07.07.2023
Просмотров: 348
Скачиваний: 10
ВВЕДЕНИЕ
Программная инженерия (промышленное программирование) обычно ассоциируется с разработкой больших и сложных программ коллективами разработчиков. Становление и развитие этой области деятельности было вызвано рядом проблем, связанных с высокой стоимостью программного обеспечения, сложностью его создания, необходимостью управления и прогнозирования процессов разработки. В конце 60-х – начале 70-х годов прошлого века произошло событие, которое вошло в историю как первый кризис программирования. Событие состояло в том, что стоимость программного обеспечения стала приближаться к стоимости аппаратуры («железа»), а динамика роста этих стоимостей позволяла прогнозировать, что к середине 90-годов все человечество будет заниматься разработкой программ для компьютеров. Тогда и заговорили о программной инженерии (или технологии промышленного программирования, как это называлось в России) как о некоторой дисциплине, целью которой является сокращение стоимости программ. С тех пор программная инженерия прошла достаточно бурное развитие. Этапы развития программной инженерии можно выделять по-разному. Каждый этап связан с появлением (или осознанием) очередной проблемы и нахождением путей и способов решения этой проблемы Сам термин – software engineering (программная инженерия) - впервые был озвучен в октябре 1968 года на конференции подкомитета НАТО по науке и технике (г. Гармиш, Германия). Присутствовало 50 профессиональных разработчиков ПО из 11 стран. Рассматривались проблемы проектирования, разработки, распространения и поддержки программ. Там впервые и прозвучал термин «программная инженерия» как некоторая дисциплина, которую надо создавать и которой надо руководствоваться в решении перечисленных проблем. Вскоре после этого в Лондоне состоялась встреча 22-х руководителей проектов по разработке ПО. На встрече анализировались проблемы и перспективы развития ПО. Отмечалась возрастающее воздействие ПО на жизнь людей. Впервые серьезно заговорили о надвигающемся кризисе ПО. Применяющиеся принципы и методы разработки ПО требовали постоянного усовершенствования. Именно на этой встрече была предложена концепция жизненного цикла ПО (SLC – Software Lifetime Cycle) как последовательности шагов-стадий, которые необходимо выполнить в процессе создания и эксплуатации ПО.
1. ОБЩИЕ ПРИНЦИПЫ ПРОГРАММНОЙ ИНЖЕНЕРИИ: ЭФФЕКТИВНОСТЬ, ПОВТОРНОЕ ИСПОЛЬЗОВАНИЕ, НАДЕЖНОСТЬ, СТОЙКОСТЬ К ОШИБКАМ
Основные компоненты CS-науки: Computer Engineering (компьютерная инженерия), System Engineering (системная инженерия), Software Engineering (SE – программная инженерия), соответствующая ТП. Согласно энциклопедии СS (1992) приведем краткое определение этих инженерных дисциплин СS. Компьютерная инженерия – это теории, принципы и методы построения компьютеров (frameworks, суперкомпьютеров и т.п.), а также системного ПО ЭВМ (ОС, трансляторов, загрузчиков и т.д.). Системная инженерия – это теория, методы и принципы построения информационных систем, систем управления и Computer Systems. Программная инженерия – это система методов, способов и дисциплин планирования, разработки, эксплуатации и сопровождения ПО. Принципам и методам построения информационных систем (ИС) В.М. Глушков посвятил свой последний научный труд «Безбумажная информатика» (1982) [8]. В нем информационные системы – это компьютерные системы обработки информации на предприятиях, в органах управления и в производственной сфере. Базис таких систем – документы, не бумажные, а электронные, и система документооборота на всех уровнях управления государственных предприятий и органов. Информационные технологии (ИТ) – базис компьютерной инфраструктуры современных корпораций, предприятий и государственных органов управления, на которых главным источником деятельности является информация и решение различных задач обработки информации локального и глобального характера.
1.1 Основы и принципы программной инженерии
Программы различаются по назначению, выполняемым функциям, формам реализации. Однако можно полагать, что существуют некоторые общие принципы, которые следует использовать при разработке программ.
Частотный принцип - основан на выделении в алгоритмах и данных особых групп по частоте использования. Для действий, наиболее часто встречающихся при работе программ, создаются условия их быстрого выполнения. К часто используемым данным обеспечивается наиболее быстрый доступ. «Частые» операции стараются делать более короткими. Следует отметить, что лишь не более 5 % операторов программы оказывают ощутимое влияние на скорость выполнения программы. Этот факт позволяет значительную часть операторов программы кодировать без учета скорости вычислений, обращая основное внимание при этом на «красоту» и наглядность текстов.
Принцип модульности - в данном контексте понимают функциональный элемент рассматриваемой системы, имеющий оформление, законченное и выполненное в пределах требований системы, и средства сопряжения с подобными элементами или элементами более высокого уровня данной или другой системы. Способы обособления составных частей программ в отдельные модули могут различаться существенно. В значительной степени разделение системы на модули определяется используемым методом проектирования программ.
Принцип функциональной избирательности - является логическим продолжением частотного и модульного принципов и используется при проектировании программ. В программах выделяется некоторая часть важных модулей, которые постоянно должны быть в состоянии готовности для эффективной организации вычислительного процесса. Эту часть в программах называют ядром или монитором. При формировании состава монитора требуется учесть два противоречивых требования. В состав монитора, помимо чисто управляющих модулей, должны войти наиболее часто используемые модули. Количество модулей должно быть таким, чтобы объем памяти, занимаемой монитором, был не слишком большим. Программы, входящие в состав монитора, постоянно хранятся в оперативной памяти. Остальные части программ постоянно хранятся во внешних запоминающих устройствах и загружаются в оперативную память только при необходимости, перекрывая друг друга также при необходимости.
Принцип генерируемости - основное положение этого принципа определяет такой способ исходного представления программы, который бы позволял осуществлять настройку на конкретную конфигурацию технических средств, круг решаемых проблем, условия работы пользователя.
Принцип функциональной избыточности - учитывает возможность проведения одной и той же работы различными средствами. Особенно важен учет этого принципа при разработке пользовательского интерфейса для выдачи одних и тех же данных разными способами вызова из-за психологических различий в восприятии информации.
Принцип «по умолчанию» - применяется для облегчения организации связей с системой, как на стадии генерации, так и при работе с уже готовыми программами. Принцип основан на хранении в системе некоторых базовых описаний структур, модулей, конфигураций оборудования и данных, определяющих условия работы с программой. Эту информацию программа использует в качестве заданной по умолчанию, если пользователь забудет или сознательно не конкретизирует ее.
1.2 Эффективность программной инженерии
Эффективность – требует поиска специальных архитектурных решений, выбора каналов передачи с требуемыми характеристиками и оптимизации программного кода.
Задачи рационального сочетания целей, стратегий действий, конкретных процедур и доступных ресурсов необходимо решать для достижения основной цели — получения программного продукта с заданными функциональными характеристиками и качеством. Базой эффективного управления проектом программного комплекса является план, в котором задачи исполнителей частных работ должны быть согласованы с выделяемыми для них ресурсами, а также между собой, по результатам и срокам их достижения. Планирование программных проектов должно обеспечивать компромисс между требующимися характеристиками создаваемой системы и ограниченными ресурсами, необходимыми на ее разработку и применение. По мере уточнения исходных требований к объекту разработки, внешней среде применения и ресурсам, в процессе системного анализа и проектирования возрастает достоверность планирования, которое должно проходить этапы:
● обследование объектов и среды проектирования для предварительной формализации целей, назначения и задач проекта;
● первичное прогнозирование возможных характеристик и требований к программному продукту на базе обобщения данных ранее реализованных подобных прототипов и создание концепции проекта;
● подготовка предварительного плана выполнения этапов и частных работ с учетом допустимых затрат ресурсов на их реализацию;
● управление детализацией и реализацией плана производства, его оперативной корректировкой и перераспределением возможных ресурсов в соответствии с особенностями развития компонентов программного комплекса;
● обобщение и накопление результатов планирования и управления конкретным проектом для использования этих данных в качестве прототипов при производстве программных продуктов.
На каждом этапе должен проводиться поиск эффективных технически -инженерные решения реализации проекта, исследование и сопоставление альтернативных действий, которые должны приводить к достижению поставленных целей производства программного продукта. В результате процессы планирования проекта и его выполнения обычно развиваются параллельно. Уже при первичном прогнозировании развития проекта должны оцениваться альтернативные характеристики объекта и среды разработки и выбираться наиболее подходящие для производства в соответствии с поставленными целями и имеющимися ресурсами. Сравнение альтернатив следует проводить по величине достигаемого эффекта проекта в зависимости от затрат на его достижение (желательно, по показателю «эффективность/стоимость»).
Программные комплексы все больше встраиваются в различные заказные технические системы. Работа с такими проектами требует от программных специалистов широкого взгляда на общие технические и инженерные задачи проектирования сложных систем. Специалистам занимающимся аналитикам программных проектов необходимо участвовать в выработке требований для всей системы, а также понимать прикладную область применения продукта еще до начала обдумывания функций компонентов и их интерфейсов, требованиям которых должен будет отвечать программный продукт.
1.2 Аспект: повторное использование
Под этим подразумевается, повторное эксплуатация продукта с возможность удержать потребителя для повторной покупки ПО и завлекания во все сторонние продукты от разработчика, издателя и магазина.
Так же существует хороший факт, позволяющий акцентироваться на возможности улучшения процесса. Возможность повторного использования программного обеспечения не препятствует улучшению процесса.
Если задуматься о процессах, которые входят в создание программного обеспечения - разработка требований, проектирование системы, внедрение системы, развертывание системы, управление требованиями, управление конфигурациями, проверка и проверка работоспособности, отслеживание изменений и ряд других, то они повторяются на каждый проект, независимо от того, сколько у вас повторного использования. Кроме того, каждый из них имеет количественные и качественные меры, которые могут быть использованы для определения того, насколько хорош этот конкретный процесс или деятельность, и, как результат, насколько хорош процесс развития в целом.
В крайнем случае можно взять надежную линейку программных продуктов и смерить с сопоставимой конкуренции причаствующим в повторном использовании продукта. С другой стороны, вы можете предполагать разработку новых месторождений. Все еще необходимо выполнять все эти процессы в разной степени, хотя они могут происходить с разной скоростью или, возможно, даже в разных последовательностях. Например, при большом количестве повторного использования большая часть выделенного времени может быть потрачена на интеграцию и проверку /проверку на системном уровне. При новых усилиях по развитию в процессе проектирования и реализации может потребоваться больший процент времени. Пока вы выполняете процесс хотя бы один раз в ходе проекта, его можно измерить (количественно и качественно). После того, как вы внесете корректировки и посмотрите, как эти корректировки влияют на некоторую меру как области процесса, так и общей возможности доставки программного обеспечения, а затем уточняют процесс для других проектов.