ВВПИ. Лекция 1. Программная инженерия. Лекция 1 Программная инженерия назначение, основные принципы и понятия 1 Предпосылки и история
 Скачать 0.74 Mb.
|
|
1 Лекция 1 Программная инженерия: назначение, основные принципы и понятия 1.1 Предпосылки и история В конце 60-х – начале 70-х годов прошлого века произошло событие, которое во- шло в историю как первый кризис программирования. Событие состояло в том, что стои- мость программного обеспечения стала приближаться к стоимости аппаратуры («железа»), а динамика роста этих стоимостей позволяла прогнозировать, что к середине 90-годов все человечество будет заниматься разработкой программ для компьютеров. Тогда и загово- рили о программной инженерии (или технологии программирования, как это называлось в России) как о некоторой дисциплине, целью которой является сокращение стоимости про- грамм. С тех пор программная инженерия прошла достаточно бурное развитие. Этапы раз- вития программной инженерии можно выделять по-разному. Каждый этап связан с появ- лением (или осознанием) очередной проблемы и нахождением путей и способов решения этой проблемы. На слайде представлены ряд фундаментальных проблем разработки про- грамм и найденных фундаментальных методов их решения. Эти методы и по сей день со- ставляют основу подходов к проектированию программных продуктов. 1.1.1. Повторное использование кода (модульное программиро- вание) Проблема. На первых этапах становления программной инженерии (даже когда она так еще не называлась) было отмечено, что высокая стоимость программ связана с разра- боткой одинаковых (или похожих) фрагментов кода в различных программах. Вызвано это было тем, что в различных программах как части этих программ решались одинаковые (или похожие) задачи: решение нелинейных уравнений, расчет заработной платы, … Ис- пользование при создании новых программ ранее написанных фрагментов сулило суще- ственное снижение сроков и стоимости разработки. Модульное программирование. Главный принцип модульного программирования состоял в выделении таких фрагментов и оформлении их в виде модулей. Каждый модуль снабжался описанием, в котором устанавливались правила его использования – интерфейс модуля. Интерфейс задавал связи модуля с основной программой – связи по данным и связи по управлению. При этом возможность повторного использования модулей опреде- лялась количеством и сложностью этих связей, или насколько эти связи удалось согласо- вывать с организацией данных и управления основной программы. Наиболее простыми в этом отношении оказались модули решения математических задач: решения уравнений, систем уравнений, задач оптимизации. К настоящему времени накоплены и успешно ис- пользуются большие библиотеки таких модулей. Для многих других типов модулей возможность их повторного использования ока- залась проблематичной в виду сложности их связей с основной программой. Например, модуль расчета зарплаты, написанный для одной фирмы, может не подойти для другой, т.к. зарплата в этих фирмах рассчитывается не во всем одинаково. Повторное использова- ние модулей со сложными интерфейсами является достаточно актуальной и по сей день. Для ее решения разрабатываются специальные формы (структуры) представления моду- лей и организации их интерфейсов. 1.1.2. Рост сложности программ (структурное программирование) Проблема. Следующий этап возрастания стоимости ПО был связан с переходом от разработки относительно простых программ к разработке сложных программных ком- 2 плексов. К числу таких сложных программ относятся: системы управления космическими объектами, управления оборонным комплексом, автоматизации крупного финансового учреждения и т.д. Сложность таких комплексов оценивалась следующими показателями: 1. Большой объем кода (миллионы строк) 2. Большое количество связей между элементами кода 3. Большое количество разработчиков (сотни человек) 4. Большое количество пользователей (сотни и тысячи) 5. Длительное время использования Для таких сложных программ оказалось, что основная часть их стоимости прихо- дится не на создание программ, а на их внедрение и эксплуатацию. По аналогии с про- мышленной технологией стали говорить о жизненном цикле программного продукта, как о последовательности определенных этапов: этапа проектирования, разработки, тестиро- вания, внедрения и сопровождения. Структурное программирование. Этап сопровождения программного комплекса включал действия по исправлению ошибок в работе программы и внесению изменений в соответствии с изменившимися требованиями пользователей. Основная причина высокой стоимости (а порой и невозможности выполнения) этапа сопровождения состояла в том, что программы были плохо спроектированы – документация была не понятна и не соот- ветствовала программному коду, а сам программный код был очень сложен и запутан. Нужна технология, которая обеспечит «правильное» проектирование и кодирование. Ос- новные принципы технологии структурного проектирования и кодирования: 1. Нисходящее функциональное проектирование, при котором в системе выделяются основные функциональные подсистемы, которые потом разбиваются на подсисте- мы и т.д. (принцип «разделяй и властвую») 2. Применение специальных языков проектирования и средств автоматизации ис- пользования этих языков 3. Дисциплина проектирования и разработки: планирование и документирование про- екта, поддержка соответствие кода проектной документации 4. Структурное кодирование без goto 1.1.3. Модификация программ (ООП) Проблема. Следующая проблема роста стоимости программ была вызвана тем, что изменение требований к программе стали возникать не только на стадии сопровождения, но и на стадии проектирования – проблема заказчика, который не знает, что он хочет. Со- здание программного продукта превратилось в его перманентное перепроектирование. Возник вопрос, как проектировать и писать программы, чтобы обеспечить возможность внесений изменений в программу, не меняя ранее написанного кода. Объектно-ориентированное программирование. Решением этой проблемы стало использование подхода или метода, который стали называть объектно-ориентированным проектированием и программированием. Суть подхода состоит в том, что вводится поня- тие класса как развитие понятия модуля с определенными свойствами и поведением, ха- рактеризующими обязанностями класса. Каждый класс может порождать объекты – эк- земпляры данного класса. При этом работают основные принципы (парадигмы) ООП: 1. Инкапсуляция – объединение в классе данных (свойств) и методов (процедур обра- ботки). 2. Наследование – возможность вывода нового класса из старого с частичным изме- нением свойств и методов 3. Полиморфизм – определение свойств и методов объекта по контексту Проиллюстрировать возможности принципов ООП можно на следующем примере. В организации, состоящей из трех отделов надо начислять заработную плату. В програм- ме каждый отдел представлен своим модулем – объектом, а начисление зарплаты – объек- том «Зарплата». При необходимости расчета зарплаты объекту «Отдел» передается экзем- 3 пляр объекта «Зарплата». Объект «Отдел» передает объекту «Зарплата» необходимые данные и затем с помощью методов объекта «Зарплата» выполняет необходимые расчеты. В отделе 3 частично изменились правила начисления зарплаты. В этой ситуации при объектно-ориентированном подходе из класса «Зарплата» выводится класс «Зарплата 1», который наследует неизменившиеся правила начисления зарплаты и переопределяет изменившиеся. Здесь при расчете зарплаты объектам «Отдел 1» и «Отдел 2» будет пере- даваться объект «Зарплата», а объекту «Отдел 3» - объект «Зарплата 1». При таких изме- нениях: 1. Срабатывает принцип наследования: код «Зарплата», «Отдел 1» и «Отдел 2» оста- ются без изменения, а код «Зарплата 1» изменяется ровно настолько, насколько это необходимо. 2. Срабатывает принцип полиморфизма: код «Отдел 3» также не изменяется – он продолжает считать, что работает с объектом «Зарплата» 1.1.4. Некоторые итоги Программная инженерия (или технология программирования) как некоторое направление возникло и формировалось под давлением роста стоимости создаваемого программного обеспече- ния. Главная цель этой области знаний - сокращение стоимости и сроков разработки программ. Программная инженерия прошла несколько этапов развития, в процессе которых были сформулированы фундаментальные принципы и методы разработки программных продуктов. Ос- новной принцип программной инженерии состоит в том, что программы создаются в результате выполнения нескольких взаимосвязанных этапов (анализ требований, проектирование, разработка, внедрение, сопровождение), составляющих жизненный цикл программного продукта. Фундамен- тальными методами проектирования и разработки являются модульное, структурное и объектно- ориентированное проектирование и программирование. 1.1.5. Продолжение кризиса программирования Несмотря на то, что программная инженерия достигла определенных успехов, перманент- ный кризис программирования продолжается. Связано это с тем, рубеж 80–90-х годов отмечается как начало информационно-технологической революции, вызванной взрывным ростом использо- вания информационных средств: персональный компьютер, локальные и глобальные вычисли- тельные сети, мобильная связь, электронная почту, Internet и т.д. Цена успеха – кризис программирования принимает хронические формы: • США тратит ежегодно более $200 млрд. на более чем 170 тыс. проектов разработки ПО в сфере IT; • 31,1% из них закрываются, так и не завершившись; 52,7% проектов завершаются с превы- шением первоначальных оценок бюджета/сроков и ограниченной функциональностью; • потери от недополученного эффекта внедрения ПО измеряются триллионами. Статистика по 30,000 проектам по разработке ПО в американских компаниях показывает следующее распределение между: • Успешными – вовремя и в рамках бюджета был выполнен весь намеченный фронт работ • Проблемными – нарушение сроков, перерасход бюджета и/или сделали не все, что требо- валось • Проваленными – не были доведены до конца из-за перерасхода средств, бюджета, качества. Источник: The Standish Group International The Standish Group International, Inc., Extreme Chaos, 2000 - http://www1.standishgroup.com//sample_research/PDFpages/extreme_chaos.pdf 4 1.2 Программная инженерия – что это такое? 1.2.1. Начнем с определений На сегодняшний день нет единого определения понятия «программная инженерия». На слайде приведено несколько таких определений, данных крупными специалистами в этой области, или зафиксированные в документах ведущих организаций. Сам термин – software engineering (программная инженерия) - впервые был озвучен в октябре 1968 года на конференции подкомитета НАТО по науке и технике (г.Гармиш, Германия). Присутствовало 50 профессиональных разработчиков ПО из 11 стран. Рас- сматривались проблемы проектирования, разработки, распространения и поддержки про- грамм. Там впервые и прозвучал термин «программная инженерия» как некоторая дисци- плина, которую надо создавать и которой надо руководствоваться в решении перечислен- ных проблем. Вскоре после этого в Лондоне состоялась встреча 22-х руководителей проектов по разработке ПО. На встрече анализировались проблемы и перспективы развития ПО. От- мечалась возрастающее воздействие ПО на жизнь людей. Впервые серьезно заговорили о надвигающемся кризисе ПО. Применяющиеся принципы и методы разработки ПО требо- вали постоянного усовершенствования. Именно на этой встрече была предложена кон- цепция жизненного цикла ПО (SLC – Software Lifetime Cycle) как последовательности ша- гов-стадий, которые необходимо выполнить в процессе создания и эксплуатации ПО. Во- круг этой концепции было много споров. В 1970 г. У.У. Ройс (W.W. Royce) произвел идентификацию нескольких стадий в типичном цикле и было высказано предположение, что контроль выполнения стадий приведет к повышению качества ПО и сокращению сто- имости разработки. 1.2.2. Разберемся в вопросах Для того, чтобы получить представление о том, что такое программная инженерия, попробуем разобраться в следующих вопросах: • Что такое программное обеспечение (software)? • Что такое программная инженерия? • В чем разница между программной инженерией (software engineering) и информа- тикой (computer science)? • В чем разница между программной инженерией и системной инженерией (systems engineering)? • В чем отличие программной инженерии от других инженерий? 1.2.3. Что такое программное обеспечение (software)? Программное обеспечение это набор компьютерных программ, процедур и связанной с ними документации и данных (ISO/IEC 12207). Взгляд на ПО как только на программу, сидящую в компьютере слишком узок. Дело в том, что продается (поставляется) не только программа, но еще и документация, в которой можно прочитать как установить программу и как ей пользоваться и данные для установки программы в различных условиях (конфигурационные файлы). Поэтому ПО иногда называют программным продуктом. Т.е. программный продукт (программное обеспечение) – это не только программы, а также вся связанная с ними документация и конфигурационные дан- ные, необходимые для корректной работы программы. А специалисты по программному обеспе- чению разрабатывают программные продукты, т.е. такое ПО, которое может быть продано потре- бителю. В зависимости от того, для кого разрабатываются программные продукты (конкретного за- казчика или рынка, программные продукты бывают двух типов: • коробочные продукты (generic products – общие продукты или shrink-wrapped software – упакованное ПО) 5 • заказные продукты (bespoke – сделанный на заказ или customized products – настроенный продукт). Важная разница между ними заключается в том, кто ставит задачу (определяет, или специфицирует требования). В первом случае это делают сами разработчики на основе анализа рынка (маркетинга) – и при этом рискуют сами. Во втором – заказчик и при этом рискует, что разработчик не сможет реально выполнить все требования в срок и при выде- ленном бюджете. 1.2.4. Что такое программная инженерия? Программная инженерия — это инженерная дисциплина, которая связана со всеми аспектами производства ПО от начальных стадий создания спецификации до поддержки системы после сдачи в эксплуатацию. В этом определении есть две ключевые фразы: • Инженерная дисциплина • Все аспекты производства ПО Инженерная дисциплина. Инженеры – это те специалисты, которые выполняют практическую работу и добиваются практических результатов. Ученый может сказать: проблема неразрешима в рамках существующих теорий и это будет научный результат, достойный опубликования и защиты диссертации. Для решения задачи инженеры применяют теории, методы и средства, пригодные для решения данной задачи, но они применяют их выборочно и всегда пытаются найти решения, даже в тех случаях, когда теорий или методов, соответствующих данной задаче, еще не существует. В этом случае инженер ищет метод или средство для решения задачи, применяет его и несет ответственность за результат – ведь метод или средство еще не проверены. Набор таких инженерных методов или способов, теоретически возможно не обоснованных, но получивших неоднократное подтверждение на практике, играет боль- шую практическую роль. В программной инженерии они получили название лучших практик (best practices). Инженеры работают в условиях ограниченных ресурсов: временных, финансовых и организационных (оборудование, техника, люди). Иными словами, продукт должен быть создан в установленные сроки, в рамках выделенных средств, оборудования и людей. Хо- тя это в первую очередь относится к созданию заказных продуктов (оговаривается в усло- виях контракта), но при создании коробочных продуктов эти ограничения имеют не меньшее значение, т.к. здесь они диктуются условиями рыночной конкуренции. Все аспекты производства ПО. Программная инженерия занимается не только тех- ническими вопросами производства ПО (специфицирование требований, проектирование, кодирование,…), но и управлением программными проектами, включая вопросы планиро- вания, финансирования, управления коллективом и т.д. Кроме того, задачей программной инженерии является разработка средств, методов и теорий для поддержки процесса про- изводства ПО. Программные инженеры применяют систематичные и организованные подходы к работе для достижения максимальной эффективности и качества ПО. Их задача состоит в адаптации существующих методов и подходов к решению свой конкретной проблемы. 1.2.5. В чем отличия от информатики? Информатика (computer science) занимается теорией и методами вычислительных и программных систем, в то время как программная инженерия занимается практическими проблемами создания ПО. Информатика составляет теоретические основы программной инженерии и инженер по программному обеспечению должен знать информатику. Так же, как инженер по электронике должен знать физику. В идеале, программная инженерия должна быть поддержана какими-то теориями информатики, но самом деле это не всегда так. Программные инженеры зачастую используют приемы, которые применимы только в конкретных условиях и не могут быть обобщены на другие случаи, а элегантные теории информатики не всегда могут быть применены к реальным большим системам. 6 И наконец, информатика – это не единственный теоретический фундамент про- граммной инженерии, т.к. круг проблем, стоящих перед программным инженером значи- тельно шире просто написания программ. Это еще управление финансами, организация работ в коллективе, взаимодействие с заказчиком и т.д. Решение этих проблем требуют фундаментальных знаний, выходящих за рамки информатики. 1.2.6. В чем отличие от других инженерий? Отличие программной инженерии от других инженерий интересно прежде всего с точки зрения двух вопросов: • Почему доля провальных проектов в программной инженерии так велика по срав- нению с другими инженериями? • Можно ли в программной инженерии применять опыт других инженерий? Эти вопросы является фундаментальными для программной инженерии. По этому поводу высказывается много мнений (и часто противоположных). Остановимся на неко- торых более или менее очевидных отличиях программной инженерии от других инжене- рий. Прежде всего, отметим, что жизненный цикл продукта любой инженерии в упро- щенном виде включает фазы: проектирование, создание образца, испытание, производство, эксплуатация. Компьютерная программа – это (в отличие от объектов других инженерий) не ма- териальный объект (просьба не путать с носителем программы – устройством памяти лю- бого типа). Отсюда следуют следующие отличия. Фаза производства состоит в копирова- нии образца на другие носители. Стоимость фазы исчезающее мала. Если кодирование считать элементом проектирования (что очень близко к истине), то отсутствует также и фаза создания образца (строится компилятором и линковщиком) Отсюда следуют следующие выводы: Стоимость программы – это стоимость только ее проектирования Стоимость проектирования коробочных продуктов «размазывается» по ко- пиям Стоимость заказных продуктов (массово не копируемых) остается высокой |