Методы программной инженерии?

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

Начиная с 70-х годов создано достаточно много методов разработки ПО. Наиболее известны:

• Метод структурного анализа и проектирования Том ДеМарко (1978),

• Метод сущность-связь проектирования информационных систем Чен (1976)

• Метод объектно-ориентированного анализа Буч (1994), Рамбо (1991).

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

Методы должны включать в себя следующие компоненты:

• Описание моделей системы и нотация, используемая для описания этих моделей (например, объектные модели, конечно-автоматные модели и т.д.)

• Правила и ограничения, которые надо выполнять при разработке моделей (например, каждай объект должен иметь одинаковое имя)

• Рекомендации — эвристики, характеризующие хорошие приемы проектирования в данном методе (скажем, рекомендация о том, что ни у одного объекта не должно быть больше семи подобъектов)

• Руководство по применению метода — описание последовательности работ (действий), которые надо выполнить для построения моделей (все атрибуты должны быть задокументированы до определения операций, связанных с этим объектом)

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

1.2.12.1. Модель прецедентов (требований)

На слайде представлена модель прецедентов, или вариантов использования (Use case) в нотации языка UML (Unified Modeling Language), поддерживающего объектно-ориентированный анализ и проектирование ПО. Модель описывает (специфицирует) требования к программе регистрации курсов в ВУЗе.

На диаграмме представлены действующие лица (акторы) и действия (прецеденты), которые они выполняют:

· Студент регистрируется на курсе

· Преподаватель: выбирает курс для преподавания и запрашивает расписание курсов

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

Модель классов

На слайде представлена одна из таких моделей – диаграмма классов. На диаграмме показаны основные классы программы: ВУЗ, факультет, Студент, Курс, Преподаватель. Приведены основные атрибуты и методы классов.

Кроме того, отмечены отношения (зависимости) между классами:

· Так отмечено, что ВУЗ состоит из Факультетов (агрегация), причем, один ВУЗ может состоять из одного или нескольких факультетов.

· Каждый преподаватель работает на факультете, но при этом, каждый преподаватель может работать на нескольких факультетах и на каждом факультете могут работать несколько преподавателей.

Модель сущность-связь

На слайде представлена модель сущность-связь для задачи автоматизации продаж товаров со склада. Представлены сущности, участвующие в процессе: Покупатель, Накладная, Список товаров, Склад, … Для каждой сущности представлены ее атрибуты – для покупателя это код покупателя, имя, адрес, банк. Выделены ключевые атрибуты, однозначно идентифицирующие экземпляры сущностей (у покупателя это код). Установлены связи между сущностями: Покупатель получает Накладную. Отмечены свойства связей: один покупатель может получать несколько накладных.

Далее эта модель преобразуется в реляционную модель базы данных для хранения информации о выделенных сущностях.

Представленная на слайде модель записана в нотации IE (Information Engineering). В других нотациях она будет выглядеть иначе.

Нотации модели

На слайде представлен фрагмент модели сущность-связь задачи учета сотрудников, записанный в различных нотациях: Чена (автор метода сущность-связь), Мартина (соавтор), стандарта IDEF1X (Information Modeling Method) и Баркера.

 

Что такое CASE?

CASE - Computer Aided System Engineering - различного рода инструментальные программы, используемые для поддержки процесса создания программ

CASE средства могут быть классифицированы по нескольким признакам:

• По уровню применения:

- Upper CASE -средства анализа требований

- Middle CASE - средства проектирования

- Low CASE - cсредства разработки приложений

• Специализированные

- Средства проектирования баз данных

- Средства реинжиниринга (восстановления) модели (формирование ERD на основе анализа схем БД или формирования диаграмм на основе анализа программных кодов)

• Вспомогательные

- Планирования и управления проектом

- Конфигурационного управления

- Тестирования

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

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

Computer Aided System Engineering - использование компьютеров для поддержки процесса создания программ.

Это широкий спектр программ – инструментальных средств, применяемых на разных этапах разработки ПО: спецификации требований, проектирования, кодирования, тестирования, документирования, …

Свойства хорошей программы?

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

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

• Надежность (dependability). Надежность ПО включает такие элементы как:

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

Ø Безопасность – сбои в работе программы не должны приводить к опасным последствиям (авариям)

Ø Защищенность от случайных или преднамеренных внешних воздействий (защита от дурака, вирусов, спама).

• Эффективность (efficiency). ПО не должно впустую тратить системные ресурсы, такие как память, процессорное время, каналы связи. Поэтому эффективность ПО оценивается следующими показателями: время выполнения кода, загруженность процессора, объем требуемой памяти, время отклика и т.п.

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

Следует отметить, что реализация нефункциональных требований часто требует больших затрат, чем функциональных. Так, сопровождаемость требует значительных усилий по поддержанию соответствия проекта исходному коду и применения специальных методов создания модифицируемых программ. Надежность – дополнительных средств восстановления системы при сбоях. Эффективность – поиска специальных архитектурных решений и оптимизации кода. А удобство – проектирования не «интуитивно» понятного, а профессионально понятного интерфейса пользователя.

Основные трудности

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

• Наследование ранее созданного ПО (legacy systems). Существует достаточно много систем, созданных много лет назад, морально устаревших, но продолжающих работать. Проблема наследования таких систем состоит в их сопровождении – поддержке и развитии.

• Разнородность программных систем. ПО должно работать в распределенных сетях, на разнородном оборудовании, в разных средах, под управлением различных операционных систем.

• Сокращение времени на разработку. Запросы рынка требования к программным системам меняются очень быстро. Суть проблемы состоит в том, чтобы сократить время разработки ПО без снижения его качества.

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

1.2.16. Профессинальные и этические требования

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

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

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

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

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

• Злоупотребление компьютером – программный специалист не должны злоупотреблять компьютерными ресурсами работодателя или заказчика; под злоупотреблениями мы здесь понимаем широкий спектр — от игр в компьютерные игрушки на рабочем месте до распространения вирусов и т.п.

Кодекс этики IEEE-CS/ACM

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

• ACM – Association for Computing Machinery - Ассоцтация по вычислительной технике,

• IEEE – Institute of Electrical and Electronic Engineers – Институт инженеров по электротехнике и электронике

• CS - British Computer Society – Британское компьютерное общество

совместно разработали и опубликовали IEEE-CS/ACM Software Engineering Code of Ethics and Professional Practices – Кодекс этики и профессиональной практики программной инженерии..

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

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

Кодекс распространяется также на студентов и «подмастерьев», изучающих данную профессию

Кодекс имеет краткую и полную версии

Кодекс этики - Преамбула

Краткая версия кодекса

– суммирует стремления кодекса на высоком уровне абстракции.

– полная версия показывает как эти стремления отражаются на деятельности профессиональных программистов.

– без высших принципов детали кодекса станут казуистическими и нудными;

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

– вместе же они образуют целостный кодекс.

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

Кодекс этики: 8 принципов

1. ОБЩЕСТВО

– Программные инженеры будут действовать соответственно общественным интересам.

2. КЛИЕНТ И РАБОТОДАТЕЛЬ

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

3. ПРОДУКТ

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

4. СУЖДЕНИЕ

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

5. МЕНЕДЖМЕНТ

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

6. ПРОФЕССИЯ

– Программные инженеры будут улучшать целостность и репутацию своей профессии соответственно с интересами общества

4. КОЛЛЕГИ

– Программные инженеры будут честными по отношению к своим коллегам и будут всячески их поддерживать

8. ЛИЧНОСТЬ

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

Полная версия кодекса: IEEE-CS/ACM Software Engineering Ethics and Professional Practices. http://www.computer.org/tab/seprof/code.htm#Public

Стандартизация и стандарты

Как отмечалось, по происхождению программные продукты бывают двух типов: заказные (под заказ конкретного потребителя) и коробочные (для массовой продажи на рынке). Для заключения контракта заказчик должен быть уверен, что разработчик справится и не завалит проект. Вопрос: как его в этом убедить? Варианты ответов: «Мы умные люди с научными степенями» или «У нас есть опыт разработки подобных программ» звучат либо наивно, либо не вполне убедительно. В мировой практике промышленного производства ответы на эти вопросы дают стандарты на производство продуктов и услуг и сертификация производителей на соответствие этим стандартам. Вопрос заказчика в этом случае звучит так: Какими стандартами вы владеете и есть ли у вас сертификаты на соответствие этим стандартам?

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

Стандарты и сертификация

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

Что такое технология

Происходит от греческого téchne (искусство, мастерство) и логия (знание, умение). Определяется как:

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

• научная дисциплина, разрабатывающая и совершенствующая такие приёмы и способы;

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

• описание производственных процессов;

• инструкции по их выполнению;

• технологические правила, требования, карты, графики и др.

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

Что такое стандарт?

Происходит от английского standard - норма, образец, мерило. Это:

• утверждаемый компетентным органом нормативно-технический документ, устанавливающий комплекс норм, правил по отношению к предмету стандартизации;

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

Например: ГОСТ ЕСПД – единая система программной документации – документы, описывающие состав и структуру документации на разработку программ для ЭВМ (общее описание, техническое задание, эскизный проект, технический проект, описание применения). Типовые образцы – эталоны мер и весов (эталон метра, хранящийся в Париже в палате мер и весов).

Стандарт может быть разработан на:

• материально-технические предметы (продукцию, эталоны, образцы веществ);

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

Пример: Вузы работают в соответствии с государственными образовательными стандартами, представленными в виде паспортов специальностей.

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

Из истории стандартов: длина крепостной стены нижегородского кремля равна длине крепостной стены московского кремля. Также совпадают размеры Красной площади и площади Минина.

Что такое сертификация?

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

• каким требованиям он должен соответствовать

• каким образом возможно получить достоверные доказательства этого соответствия

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

Заявление поставщика о соответствии:

• означает, что поставщик (изготовитель) под свою личную ответственность сообщает о том, что его продукция отвечает требованиям конкретного нормативного документа

• содержит следующие сведения:

• адрес изготовителя, представляющего заявление-декларацию,

• обозначение изделия и дополнительную информацию о нем;

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

• указание о личной ответственности изготовителя за содержание заявления и др.

Заявление не является гарантией на соответствие стандарту. Заявление отражает готовность нести ответственность.

Сертификация соответствия:

• предполагает обязательное участие третьей стороны

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

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

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

• нормативные документы, на соответствие которым осуществляется сертификация;

• процедуры (схемы) сертификации;

• порядок инспекционного контроля.

Системы сертификации могут действовать на национальном, региональном и международном уровнях.

Какие бывают стандарты?

Среди всего многообразия стандартов принято выделять следующие основные типы стандартов:

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

В IT сфере известны стандарты, разработанные Microsoft, Intel, IBM.

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

Государственные стандарты (ГОСТы) принимаются государственными органами, имеют силу закона. Разрабатываются с учетом мирового опыта или на основе отраслевых стандартов. Могут иметь как рекомендательный, так и обязательный характер (стандарты безопасности). Для сертификации создаются государственные или лицензированные органы сертификации.

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