Главная страница
Навигация по странице:

  • Программа

  • Программный комплекс

  • Программное средство

  • Жизненный цикл программы

  • Профессионализм в программировании

  • Природа профессионализма такова, что чем он выше, тем он уже.

  • Лекция_1. Лекция 1 Введение в технологию разработки программных средств


    Скачать 106 Kb.
    НазваниеЛекция 1 Введение в технологию разработки программных средств
    Дата17.01.2022
    Размер106 Kb.
    Формат файлаdoc
    Имя файлаЛекция_1.doc
    ТипЛекция
    #333207

    Лекция 1

    Введение в технологию разработки программных средств
    Вопросы лекции:

    1. Предмет курса

    2. Основная терминология

    3. Краткая историческая справка

    4. Значение курса



    1. Предмет курса


    Специалисты автоматизации программного обеспечения и управления нередко участвуют в разработке прикладного про­граммного обеспечения для решения и социальных, и научных задач, поэтому им необходимо иметь представление о современных приемах программирования, технологии разработки программ, требованиях к программному обеспечению.

    Цель данной дисциплины – дать студенту систематические знания и навыки в области разработки программного обеспечения (ПО).

    Дисциплина «Технология программирования» определяет профессиональную направленность специалистов в области разработки ПО вычислительных сис­тем.
    В результате изучения дисциплины студенты должны

    ИМЕТЬ ПРЕДСТАВЛЕ­НИЕ:

    1. о проблемах и направлениях развития программных средств;

    2. о проблемах и направлениях развития технологии программирования,

    3. об основных методах и средствах автоматизации проектирования про­граммного обеспечения,

    4. о методах организации работы в коллективах разработчиков программ­ного обеспечения;


    ЗНАТЬ:

    1. этапы производства программного продукта,

    2. критерии качества программы;

    3. фазы и этапы жизненного цикла ПО;

    4. основные методы и средства разработки ПО.

    5. методы и средства тестирования программ,

    6. способы эффективной реализации абстрактных структур данных,

    7. организацию файловых систем,

    8. основные приемы сборочного программирования,

    9. методы организации работы в коллективах разработчиков,

    10. принципы построения, структуры и приемы работы с инструменталь­ными средствами, поддерживающими разработку программного обеспечения;

    11. преимущества использования объектно-ориентированного подхода при соз­дании сложных программных продуктов.


    УМЕТЬ ИСПОЛЬЗО­ВАТЬ:

    1. основные модели, методы и средства информационных технологий и спо­собы их применения для решения задач в предметных областях;

    2. объектно-ориентированные методы и средства разработки алгоритмов и программ, способы отладки, испытания и документирования программ;

    3. современные готовые библиотеки классов;

    4. современные системные программные средства, технологии и инструмен­тальные средства.

    5. организовать процесс разработки ПО;

    6. грамотно выполнить системный анализ, проектирование, кодирование, от­ладку и тестирование, документирование и выпуск программного про­дукта;

    7. осуществлять коллективную разработку;

    8. оценивать основные критерии качества созданного программного про­дукта.



    2. Основная терминология


    Технология – это набор правил, методик, инструментов, позволяющих нала­дить производственный процесс выпуска какого-либо продукта.

    Разумеется, это определение не является полным. Надо упомянуть процессы планирования, измерения, оценки качества, ответственность исполнителя и многое другое. Что касается программирования, то составляющие программного продукта очень удачно описал Брукс, а именно:

    Программа– завершенный продукт, пригодный для запуска своим автором на системе, на которой он был разработан.

    Программный продукт– программа, которую любой человек может запускать, тестировать, исправлять и развивать. Такая программа должна быть написана в обобщенном стиле, тщательно оттестирована и сопровождена подробной документацией.

    В этом определении Брукса не учтена коммерческая составляющая программ­ного продукта. Под словосочетанием "любой человек" в случае коммерческого программного обеспечения будем понимать программиста, имею­щего разрешение работать с исходными текстами программ.

    Программный комплекс– набор взаимодействующих программ, согласованных по функциям и форматам, точно определенным интерфейсам, и вкупе составляющих полное средство для решения больших задач.

    Ряд авторов дополнительно вводят определение программного средства.

    Программное средство– это программа или логически связанная совокупность программ на носителях данных, снабженная программной документацией.

    Технология программирования изучает технологические процессы и порядок их прохождения – стадии (с использованием знаний, методов и средств). Зна­ния, методы и средства могут использоваться в разных процессах и, следова­тельно, технологиях.

    Технологии удобно характеризовать в двух измерениях – вертикальном (пред­ставляющем процессы) и горизонтальном (представляющем стадии).

    Процесс – совокупность взаимосвязанных действий, преобразующих некоторые входные данные в выходные. Процессы состоят из набора действий, а каждое действие из набора задач.

    Вертикальное измерение отражает статические аспекты процессов и оперирует такими понятиями, как рабочие процессы, действия, задачи, результаты дея­тельности и исполнители.

    Стадия - часть действий по созданию программного обеспечения, ограниченная некоторым временными рамками и заканчивающаяся выпуском конкретного продукта, определяемого заданными для данной стадии требованиями. Стадии состоят из этапов, которые обычно имеют итерационный характер. Иногда ста­дии объединяют в более крупные временные рамки, называемые фазами.

    Итак, горизонтальное измерение представляет время, отражает динамические ас­пекты процессов и оперирует такими понятиями, как фазы, стадии, этапы, ите­рации и контрольные точки.

    Технологический подход определяется спецификой комбинации стадий и про­цессов, ориентированной на разные классы программного обеспечения и на особенности коллектива разработчиков.

    Жизненный цикл программыэто весь период ее разработки и эксплуатации, начиная с момента возникновения замысла и заканчивая прекращением всех видов ее использования.

    Итак, мы знаем, что программный продукт является результатом некоего производственного процесса. Этот процесс нужно спланировать, оценить ресурсы, для чего, в свою очередь, нужны более или менее точные спецификации1, что же необходимо заказчику. Затем продукт надо спроектировать в виде системы, состоящей из многих компонент, описать функции этих компонент и их связи между собой, после чего компоненты нужно запрограммировать, автономно отладить, собрать вместе, провести комплексную отладку, подготовить документацию на систему, обучить пользователей, провести опытную эксплуатацию и организовать сопровождение системы на весь период её эксплуатации.

    Разумеется, это лишь приблизительная схема, которая может варьироваться в широких пределах, но, тем не менее, она даёт представление, что такое "жизненный цикл программы" (ЖЦП). Почему "цикл"? Потому что редко бывает, когда разработка развивается столь прямолинейно, хотя одна из первых моделей ЖЦП так и называлась "водопадная", подчёркивая тот факт, что к предыдущей фазе проектирования вернуться невозможно. Работая по этой модели, коллектив последовательно разрабатывает проект – от исходной концепции до комплексного тестирования. Модель требует определить опорные точки, в которых будет оцениваться сделанное и решаться вопрос о том, можно ли двигаться дальше. Такой подход хорош для проектов, в которых требования легко формулируются с самого начала, но не годится для сложных, когда требования могут неоднократно меняться. Кроме того, водопадная модель вынуждает готовить огромную массу документации и требует единообразной процедуры оценки результатов на каждом этапе. Эти две особенности часто приводят к синдрому "аналитического паралича", напряжённым отношениям между разработчиками, заказчиками и пользователями.

    В реальной жизни это, конечно же, не так. Появляются новые требования заказчиков, изменяется аппаратура, находятся такие ошибки, которые невозможно исправить, не затронув результаты предыдущих фаз и т.д. Развитие системы – это именно циклическое повторение практически всех фаз, постоянный возврат к предыдущим фазам. Если не принять специальных мер (что, собственно, и является предметом технологии программирования), процесс может стать бесконечным.

    Одной из первых практически полезных моделей ЖЦП стала модель создания прототипов. С самого начала разработчики пытаются выделить основные, существенные требования заказчика и реализовать только их в виде работающего прототипа системы. Этот прототип показывается заказчику, часто бывает, что заказчик в ужасе кричит, что его неправильно поняли, что он хотел совсем другого, зато теперь он хоть может внятно сформулировать свои требования, глядя на работу прототипа. Цикл разработки и показа прототип повторяется несколько раз, пока заказчик не скажет: "Да, это, кажется, то, что мне нужно".

    Только после этого дорабатываются куски, выброшенные в начале разработки, подготавливается документация, короче, делается куча вещей, на которые время было бы просто выброшено, если бы их делали для самого первого, неудачного прототипа.

    Для небольших систем, особенно для тех, в которых велик процент интерактивных (взаимодействующих с пользователем) компонент, такая модель работает.

    Но есть много случаев, когда важные аспекты просто "зевались" при разработке прототипа, из-за чего позже всё приходилось переделывать заново.

    Некоторым обобщением модели создания прототипов является спиральная модель, в которой разработка приложения выглядит как серия последовательных итераций. На первых этапах уточняются спецификации продукта, на последующих добавляются новые возможности и функции. Цель этой модели – как можно раньше выявить риски и уже в первых версиях продукта устранить связанные с ним проблемы. В силу своей итеративной природы спиральная модель допускает корректировки по ходу работы, что способствует улучшению продукта. При большом числе итераций разработка по этой модели нуждается в глубокой автоматизации всех процессов, иначе она становится неэффективной. На практике у заказчиков и пользователей иногда возникает ощущение нестабильности продукта, так как они не успевают уследить за слишком быстрыми изменениями в нём. И, наконец, во многих проектах, управляемых по спиральной модели, нет чётко определённого критерия окончания работы, поэтому разработка может длиться бесконечно, поглощая финансовые ресурсы и не давая желаемой отдачи.

    Один очень важный вывод мы можем сделать даже при таком начальном знакомстве с понятием ЖЦП. Собственно программирование не является единственным занятием коллектива, занятого промышленными разработками. Более того, оно не является даже главным, наиболее трудоёмким делом. Многие исследования отдают на фазу программирования не более 15-20% времени, затраченного на разработку (сопровождение вообще бесконечно).

    Простейшее представление жизненного цикла программы представлено на рис.1.



    Рис.1. Каскадный технологический подход к ведению жизненного цикла

    Фактически, в данном случае на каждой стадии выполняется единственный процесс. Конечно, при разработке и создании больших программ такая схема недостаточно корректна (да и просто нереалистична). Однако мы можем взять ее за основу для многих других технологических подходов к ведению жизнен­ного цикла

    3. Краткая историческая справка


    В истории технологии программирования можно выделить три этапа.

    1. Осмысление опыта разработки больших систем. Понимание того, что важно не только на каком языке программирования разрабатывается программа, но и как это делается. Проведение первых международных и национальных конференций (конец 60-х - 70-е годы XX века).

      • 1968 г. – НАТО проводит первую конференцию по инженерии программирования (Software Engineering).

      • 1975 г. – 1-я международная конференция IEEE.

      • 1979 г. – 1-я Всесоюзная конференция по технологии программирования.

    2. Разработка новых технологических подходов (начало 70-х годов XX века – настоящее время).

      • 1973 г. – Дагласом Россом (Douglas Ross) разработана технология проектирования сложных систем SADT (Structured Analysis and Design Technique). Стандартизована под названием IDEF (Integrated DEFinition).

      • 1985 г. – Харланом Миллзом (Harlan Mills) сформулированы основные идеи технологии стерильного цеха.

      • 1995 г. – в октябре появилась первая пробная версия Унифицированного метода. Этот проект с 1996 года известен как UML (Unified Modeling Language). С точки зрения технологических подходов особый интерес представляет рациональный унифицированный процесс.

    3. Принятие стандартов на состав процессов жизненного цикла программного обеспечения (середина 80-х годов XX века – настоящее время). Попытки решить проблему качества программных продуктов.

      • 1985 г. – впервые утвержден стандарт жизненного цикла для проектирования программных систем (для систем военного назначения по заказам Министерство Обороны США).

      • 1994 г. – в Великобритании создан международный консорциум, разрабатывающий на постоянной основе проекты стандартов и технологии быстрого создания приложений DSDM (Dynamic Systems Development Method).

      • 1995 г. – принят международный стандарт ISO 12207:1995 In­formation Technology – Software Life Cycle Processes", регламентирующий состав процессов жизненного цикла программного обеспечения.



    4. Значение курса


    Курс “Технология программирования” имеет целью дальнейшее знакомство сту­дентов с современным программным обеспечением, принципами его разработки. В настоящее время программирование все больше становится занятием для про­фессионалов. Разработано большое количество программных средств, применяемых для решения широкого круга задач. И хотя только в случае, ко­гда имеющееся программное обеспечение не дает возможности решить задачу, следует прибегнуть к программированию, таких случаев меньше не становится.

    В нашем курсе рассматриваются вопросы, над которыми рано или поздно задумываются все программисты.

    • Каковы функции, черты и особенности мышления профессиональных программистов?

    • Является программирование искусством, наукой или ремеслом?

    • Что должны знать и уметь профессиональные программисты?

    • Существуют ли стандарты для обучения программированию?

    • Почему многие программные проекты выполняются с отставанием от графика, с превышением сметы расходов, а качество продукта не устраивает пользователя?

    Здесь мы приведем основные понятия и определения из области профессионального программирования.

    Профессионализм в программировании

    Каждое очередное пятилетие приносит нам новый взгляд на программирование:

    - экстравагантный промежуточный этап в решении задачи,

    - математическая головоломка, дело необычайной трудности, доступное лишь посвященным,

    - своеобразное инженерное конструирование, особого рода логическое рассуждение, наконец,

    - основа любой целеустремленной деятельности, вторая грамотность современного образованного человека.

    Кто такой профессионал? Этим словом мы называем человека, который занимается каким - либо делом не просто как специалист, но и демонстрирует профессионализм – отличное владение своей профессией (в нашем случае – программированием).

    Профессионализм – это интегральная личностная характеристика человека (программиста), который:

    • овладел нормами профессиональной деятельности и общения и осуществляет их на высоком уровне, добиваясь профессионального мастерства в своей области (программировании);

    • следует профессиональной ценностной ориентации, соблюдая профессиональную этику;

    • развивает свою личность средствами профессии;

    • стремится внести творческий вклад в профессию, обогащая ее опыт;

    • стремится и умеет вызвать интерес общества к результатам своей профессиональной деятельности, способствует повышению веса и престижа своей профессии в обществе, гибко учитывает новые запросы общества к ней.

    Профессионализм закладывается в процессе общего и профессионального образования, в отличие от мастерства, которое может быть накоплено в опыте и подражании.

    Природа профессионализма такова, что чем он выше, тем он уже.

    Наряду с понятием "профессионализм" используют также понятия "образованность" и "компетентность".

    Образованность – это наличие разносторонних знаний. В отличие от профессионализма, образованность, чем выше – тем шире.

    Высокообразованный программист – это не только безукоризненный специалист в определенной области программирования, но и человек, имеющий широкий взгляд на современное программирование независимо от языков и платформ, которые он сейчас конкретно использует. Это также человек, уверенно ориентирующийся в других сферах науки и искусства, знающий философию, историю, владеющий иностранными языками.

    Компетентность – это осведомленность в целом ряде компонентов, имеющих надпрофессиональный или внепрофессиональный характер и в то же время абсолютно необходимых сегодня в той или иной степени каждому программисту. Компетентность проявляется в таких качествах личности, как самостоятельность, способность принимать ответственные решения, творческий подход к любому делу и умение довести его до конца, коммуникабельность, умение вести диалог. Просто незаменимыми качествами программиста являются умение постоянно учиться и обновлять свои знания, гибкость мышления и наличие абстрактного, системного и экспериментального мышления.

    Результаты программирования играют важнейшую роль во многих областях человеческой деятельности. Программирование привлекает как престижностью этой профессии, так и потенциально высокими заработками. Однако часто можно встретить людей, которые узнали, что написать небольшие программы – не очень сложно, и переносят такое мнение на программирование вообще. Итак, нужны ли программисты – профессионалы в настоящее время, когда каждый выпускник школы может написать программу? А нужны ли профессиональные писатели, когда все сами грамотные? Ответ очевиден. И мы надеемся, что этот курс поможет вам стать настоящим образованным и компетентным профессионалом.

    На туманной заре информационно-компьютерной юности, в доДОСовскую эпоху, когда программы еще не стали товаром, а были скорее произведениями искусства, существовало нечто вроде натурального программного хозяйства. "На своем дворе", в стабильном программном окружении, на той же машине, на которой проходила отладка, программы достойно отрабатывали возложенные на них обязанности. Эдакая идиллия истоков отрасли.

    Став товаром, программное обеспечение отторглось от родного гнезда (аппаратура + системное ПО) и показало всю свою своеобразную, непредсказуемую натуру. Особенности производства такого товара состоят, прежде всего, в переносе центра тяжести с массового дублирования готового программного обеспечения на разработку, отладку и послепродажную корректировку и поддержку версий. С одной стороны, трудно ошибиться при дублировании запущенного в серию продукта, с другой – легко пропустить ошибку при проведении испытаний и внесении изменений. Поэтому в вопросах качества главную роль начинает играть первоначальный этап создания программного продукта с упором на его тестирование.
    Контрольные вопросы:

    1. Дайте определение технологии, программы, программного продукта и комплекса, технологии программирования.

    2. Что вы понимаете под жизненным циклом программы?

    3. Опишите этапы развития технологии программирования.

    1 СПЕЦИФИКАЦИЯ - выполненный в виде таблицы документ, определяющий состав какого-либо изделия. Содержит обозначение составных частей, их наименование и количество (основной документ, используемый для комплектования изделий).



    написать администратору сайта