Мегаобучалка Главная | О нас | Обратная связь


Лекция 1: Программная инженерия



2018-07-06 1108 Обсуждений (0)
Лекция 1: Программная инженерия 0.00 из 5.00 0 оценок




Отличия п-ия от ПИ:

- П-ие - абстрактная деятельность;

- П-ие может происходить во многих различных контекстах.

Промышленное п-ие:

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

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

Чтобы удовлетворить этим дополнительным требованиям, программирование "обрастает" различными дополнительными видами деятельности: разработкой требований, планированием, тестированием, конфигурационным управлением, проектным менеджментом, созданием различной документации (проектной, пользовательской и пр.).

Определение ПИ:

ПИ (softwareengineering) называются все дополнительные виды деятельности, выполняемые в процессе промышленного программирования и необходимые для успешного выполнения заказов.(научная дисциплина)

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

Дополнительные виды деятельности, выполняемые в процессе промышленного программирования и необходимые для успешного выполнения заказов:

1. Разработка программного кода предваряется:

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

- проектированием, то есть предварительный макет, эскиз, план системы на бумаге.

2. Специальные усилия по организации процесса разработки.

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

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

4. Система разбивается на компоненты, удобные в разработке, годные для повторного использования и интеграции. А также имеющие необходимые характеристики по быстродействию.

5. Для этих компонент тщательно прорабатываются интерфейсы.

6. Система документируется на многих уровнях, создаются правила оформления программного кода.

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

Информатика, системотехника, бизнес-реинжиниринг в контексте ПИ:

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

Информатика (computerscience) – это свод теоретических наук, основанных на математике и посвященных формальным основам вычислимости.

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

Направленность пи и информатики различна:

- пинацелена на решение проблем производства;

- информатика – на разработку формальных, математизированных подходов к программированию.

Системотехника (systemengineering) объединяет различные инженерные дисциплины по разработке всевозможных искусственных телекоммуникационных систем, и т.д.

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

Бизнес-реинжиниринг (businessreengineering) –модернизация бизнеса в определенной компании, внедрение новых практик, поддерживаемых соответствующими новыми информационными системами.

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

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

Определение ПО:

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

Это определениезаключает в себе следующее.

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

2. Современное ПО предназначено, как правило, для одновременной работы со многими пользователями, которые могут быть значительно удалены друг от друга в физическом пространстве.

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

1. Задачи решаемые современным ПО, часто требуют различных вычислительных ресурсов в силу различной специализации этих задач, из-за большого объема выполняемой работы, а также из соображений безопасности.

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

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

СвойстваПО:

ПО является сложной динамической системой, включающей в себя технические, психологические и социальные аспекты.

ПО имеет следующие особенности:

1. Сложность программных объектов, которая существенно зависит от их размеров.

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

2. Согласованность – ПО должно быть согласовано с большим количеством интерфейсов, с которыми впоследствии оно должно взаимодействовать.

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

3. Изменяемость – ПО легко изменить и, как следствие, требования к нему постоянно меняются в процессе разработки.

Это создает много дополнительных трудностей при его разработке и эволюции.

4. Нематериальность – ПО невозможно увидеть, оно виртуально.


Лекция 2: Процесс

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

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

В рамках компании возможна и полезна стандартизация всех текущих процессов, которую будем называть стандартным процессом, который является некоторой базой данных, содержащей следующее:

- информацию, правила использования, документацию и инсталляционные пакеты средств разработки, используемых в проектах компании (систем версионного контроля, средств контроля ошибок, средств программирования;

- описание практик разработки – проектного менеджмента, правил работы с заказчиком и т.д.;

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

Основная идея стандартного процесса – курсирование внутри компании передового опыта, а также унификация средств разработки.

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

Необходимо отметить, что наличие стандартного процесса свидетельствует о наличии "единой воли" в организации, существующей именно на уровне процесса.

Определение Совершенствование процесса:

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

Причины актуальности этой деятельности для компаний-производителей ПО заключается в следующем:

- Происходит быстрая смена технологий разработки ПО, требуются изучение и внедрение новых средcтв разработки.

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

- Имеет место высокая конкуренция, которая требует поиска более эффективных, более экономичных способов разработки.

Что и каким образом можно улучшать:

- Переход на новые средства разработки, языки программирования и т.д.

- Улучшение отдельных управленческих и инженерных практик – тестирования, управления требованиями и пр.

- Полная, комплексная перестройка всех процессов в проекте, департаменте, компании (в соответствии, например, с CMMI).

- Сертификация компании (CMM/CMMI, ISO 9000 и пр.).

Главная трудность реального совершенствования процессов в компании заключается в том, что она при этом должна работать и создавать ПО.

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

Pull/Push стратегии:

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

- Organizationpull – инновации нацелены на решение конкретных проблем компании.

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

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

Пример использования стратегии technologypush – переход компании со средств структурной разработки на объектно-ориентрованные.

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

Использование стратегии organizationpull менее рискованно, вносимые ею изменения в процесс менее глобальны, более локальны. Но и выгод такие инновации приносят меньше, по сравнению с удачными внедрениями в соответствии со стратегией technologypush.

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

Еще одно различие обеих стратегий: в случае с organizationpull, как правило, возврат инвестиций от внедрения происходит быстрее, чем в случае с technologypush.

Классические модели процесса:

Процесс создания программного обеспечения не является однородным.

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

Модель является хорошей абстракцией различных методов разработки ПО, позволяя лаконично, сжато и информативно их представить.

Фазы и виды деятельности:

Говоря о моделях процессов, необходимо различать фазы и виды деятельности.

Фаза (phase) – это определенный этап процесса, имеющий начало, конец и выходной результат. Например, фаза проверки осуществимости проекта, сдачи проекта и т.д. Фазы следуют друг за другом в линейном порядке, характеризуются предоставлением отчетности заказчику и, часто, выплатой денег за выполненную часть работы.

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

Примерами фаз может служить:

- согласование с заказчиком технического задания;

- реализация определенной функциональности ПО;

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

Вид деятельности (activity) – это определенный тип работы, выполняемый в процессе разработки ПО.

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

В рамках одной фазы может выполняться много различных видов деятельности.Кроме того, один вид деятельности может выполняться на разных фазах.

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

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

Виды деятельности, фактически, присутствуют, под разными названиями, в каждом методе разработки ПО.

Водопадная модель:

Водопадная модель была предложена в 1970 году Винстоном Ройсом.

Были определены следующие шаги:

- разработка системных требований,

- разработка требований кПО,

- анализ,

- проектирование,

- кодирование,

- тестирование,

- использование.

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

Отмечалось, что такие возвраты могут катастрофически увеличить стоимость проекта и сроки его выполнения.

Например, если при тестировании обнаруживаются ошибки проектирования или анализа, то их исправление часто приводит к полной переделке системы.

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

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

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

Недостатками водопадной модели являются:

- отождествление фаз и видов деятельности, что влечет потерю гибкости разработки, в частности, трудности поддержки итеративного процесса разработки;

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

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

- пользователи и заказчик не могут ознакомиться с вариантами системы во время разработки, и видят результат только в самом конце; тем самым, они не могут повлиять на процесс создания системы, и поэтому увеличиваются риски непонимания между разработчиками и пользователями/заказчиком;

- модель неустойчива к сбоям в финансировании проекта или перераспределению денежных средств, начатая разработка, фактически, не имеет альтернатив "по ходу дела".

Применение ВМ:

Однако данная модель продолжает использоваться на практике – для небольших проектов или при разработке типовых систем, где итеративность не так востребована.

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

Спиральная модель:

Спиральная модель была предложена БэриБоемом в 1988 году для преодоления недостатков водопадной модели, прежде всего, для лучшего управления рисками.

Согласно этой модели разработка продукта осуществляется по спирали, каждый виток которой является определенной фазой разработки.

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

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

Последовательность витков может быть такой:

- на первом витке принимается решение о целесообразности создания ПО,

- на следующем определяются системные требования,

- потом осуществляется проектирование системы и т.д.

Витки могут иметь и иные значения.

Каждый виток имеет следующую структуру (секторы):

- определение целей, ограничений и альтернатив проекта;

- оценка альтернатив, оценка и разрешение рисков; возможно использование прототипирования (в том числе создание серии прототипов), симуляция системы, визуальное моделирование и анализ спецификаций; фокусировка на самых рисковых частях проекта;

- разработка и тестирование – здесь возможна водопадная модель или использование иных моделей и методов разработки ПО;

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

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

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

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


 



2018-07-06 1108 Обсуждений (0)
Лекция 1: Программная инженерия 0.00 из 5.00 0 оценок









Обсуждение в статье: Лекция 1: Программная инженерия

Обсуждений еще не было, будьте первым... ↓↓↓

Отправить сообщение

Популярное:
Почему человек чувствует себя несчастным?: Для начала определим, что такое несчастье. Несчастьем мы будем считать психологическое состояние...
Почему люди поддаются рекламе?: Только не надо искать ответы в качестве или количестве рекламы...



©2015-2020 megaobuchalka.ru Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. (1108)

Почему 1285321 студент выбрали МегаОбучалку...

Система поиска информации

Мобильная версия сайта

Удобная навигация

Нет шокирующей рекламы



(0.014 сек.)