Конвертер из SDL в объектный программный код

Specification and description language(SDL)

 
 

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

На диаграмме должны быть видны пути передачи сигналов.

Если 6 выполнено хорошо, то переход 6 ® 7 не сложен.

В RTST было по сути только 4 и 7, т.н. semantic gap (семантический разрыв). В REAL есть ещё 5 и 6.

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

Почему сложно: посылка-приём сообщения ~ 300 команд.

Удалось найти сужение, основываясь на ограничениях (переходы короткие, есть только 20% критичных объектов, можно локализовать данные), т.е. учитываем специфику предметной области. Применяется не свёртка-развёртка. Есть только один объект – ФПО (функциональное ПО), остальные объекты – вызов процедуры (~ 30 команд)


  1. Качество разработки ПО

Согласно современным международным стандартам качество программного обеспечения, как и любого другого продукта, – это его соответствие потребностям заказчика[[i]]. Самый верный путь повысить качество ПО – улучшить процесс создания и сопровождения продукта.

По данным Департамента по Торговле и Промышленности Великобритании (DTI) при внедрении проектов информационных технологий на предприятиях потери из-за некачественного программного обеспечения составляют в среднем около 20% от общего объема потерь. По разным оценкам аналогичный показатель для России достигает величины от 30 до 50%.

Промышл. Подход к качеству – Массовость, (Появление калибра - 70-е г. 19 века) 10-е годы – конвеер

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

Разделение на ф-ии и операции. Раздел. Ф-ии менеджера и исполнителя

- Фаза отбраковки

Армия контроллеров - дорого

- Фаза упр-м процесса

Контроль с пом. Статистики (

1) устойчивый

2) устойчив, новыйдет из под контроля

3) Устойчивый, но плохой

- Фаза совершенств. Качества

Деминг в Японии Каждый день маленький шаг

- Фаза планир. Качества

Больш. Проблем на основе ош. в планиров и проетиров Закон 10х увеличения на жизн цикле продукта.

Маркетинг ->Требования->Проектирование->Пр-во->Испытания->Опытная эксплотац->Сдача->…->Утилизация

- Фаза экологии качества

Его жизн. Цикл и утилизация должны быть безопасны (взрыв ракеты на старте)


  1. Стандарт качества ISO

Среди стандартов в области разработки систем качества, оценки качества процессов и уровней зрелости компаний, разрабатывающих программное обеспечение, в настоящее время наиболее популярными являются: ISO 9000 (версии 1994 и 2000 гг), ISO 12207, TickIT, SEI SW-CMM, Trilium, ISO 15504 (SPICE), CMMI.

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

· команда разработчиков, как правило, состоит из творческих личностей и часто бывает трудно привести их к «общему знаменателю»;

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

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

· по сходной причине трудно поставить производство сложного и уникального ПО на поток, так как часто для его разработки требуется создание сопутствующего специального программного «инструментария» для разработки, оптимизации и тестирования;

В 1947 г. в Лондоне представители 25 стран решили создать международную организацию, основной задачей которой стала бы координация разработок и унификация международных стандартов. Новая организация получила название International Organization for Standardization (ISO). В настоящее время ее членами являются около 100 стран.

Сегодня стандартами ISO «перекрыты» многие технологические отрасли – от программирования и телекоммуникаций до банковской и финансовой сферы.

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

Новые стандарты рождаются в соответствии с тремя принципами.

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

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

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

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

ISO 9000-3 (1991 г.). Управление качеством и гарантии качества. Часть 3. Руководство по применению стандарта ISO 9001 при разработке, установке и сопровождении ПО.

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

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

В модели ISO 9000 лишь упоминаются требования, которые должны быть реализованы, но не говорится о том, как это можно сделать. Поэтому для построения полноценной системы качества по ISO необходимо помимо основной модели ISO 9001 (1994 или 2000 года), необходимо использовать вспомогательные отраслевые и рекомендательные стандарты. Стандартизация вообще малоприменима в разработке ПО из-за творческого характера труда.

В основу построения системы качества в соответствии с моделью ISO 9000:2000 закладываются следующие принципы:

· концентрация на потребностях заказчика;

· активная лидирующая роль руководства;

· вовлечение исполнителей в процессы совершенствования;

· реализация процессного подхода;

· системный подход к управлению;

· обеспечение непрерывных улучшений;

· принятие решений на основе фактов;

· взаимовыгодные отношения с поставщиками.

Международный стандарт SPICE

В 1991 году Международная организация по стандартизации инициировала работу по созданию единого стандарта оценки программных процессов. Стандарт получил имя SPICE (сокращение от Software Process Improvement and Capability dEtermination – "Определение возможностей и улучшение процесса создания программного обеспечения"). Официально стандарт называется "ISO/IEC 15504: Information Technology - Software Process Assessment" и на данный момент существует в качестве рабочей версии, последний выпуск которой состоялся в мае 1998 года.

В SPICE существуют уровни зрелости для каждого процесса:

Уровни способностей процесса в стандарте SPICE

Уровни Название
Уровень 0 Процесс не выполняется
Уровень 1 Выполняемый процесс
1.1 Измерение производительности процесса
Уровень 2 Управляемый процесс
2.1 Управление производительностью
2.2 Управление созданием продуктов
Уровень 3 Установленный процесс

  1. Стандарт CMM

В 1986 г. SEI(Software Engineering Institute) и корпорация Mitre под руководством Уоттса Хамфри (Watts Humphrey) приступили к разработке критериев оценки зрелости технологических процессов

1991 – CMM v1.0 - The Capability Maturity Model of Software(модель зрелости возможностей)

Уровни зрелости компании в модели CMM:

1. Начальный(Initial)

· непредсказуемое качество процесса

· индивидуальные решения для каждого проекта

2. Повторяемый(Repeatable)

· Управление требованиями (Requirements management).

· Планирование проекта разработки ПО (Software project planning).

· Отслеживание хода проекта и контроль (Software project tracking and oversight).

· Управление субподрядчиками разработки ПО (Software subcontract management).

· Обеспечение уверенности в качестве разработки ПО (Software quality assurance).

· Управление конфигурацией продукта (Software configuration management).

3. Определенный(Defined)

· Цель упорядочивания работы организации (Organization Process Focus).

· Определение (стандартного) процесса организации (Organization Process Definition).

· Программа обучения (Training Program).

· Интегрированное управление разработкой ПО (Integrated Software Management).

· Технология разработки программных продуктов (Software Product Engineering).

· Межгрупповая координация (Intergroup Coordination).

Экспертные (совместные) оценки коллег (Peer Reviews).

4. Управляемый(Managed)

· Количественное управление процессом (Quantitative Process Management).

· Управление качеством ПО (Software Quality Management)

5. Оптимизированный(Optimizing)

· Предотвращение дефектов (Defect Prevention).

· Управление изменением технологий (Technology Change Management).

· Управление изменением процесса (Process Change Management).

//Большинство российских компаний – 1-2, МикроМягкие – 3-4

К преимуществам модели SEI SW-CMM относится то, что она ориентирована («заточена») на организации, занимающиеся разработкой программного обеспечения. В этой модели удалось более детально проработать требования, специфичные для процессов, связанных с разработкой ПО. Вследствие этого в SEI SW-CMM приведены не только требования к процессам организации, но и примеры реализации этих требований.

Основным же недостатком SW-CMM является то, что модель не авторизована в качестве стандарта ни международными, ни национальными органами по стандартизации. Впрочем, CMM давно уже стала промышленным стандартом де-факто.

KPA – Key Process Area – для 3-5

- Цели

- Обяз. по вып-ю

- Возможн. Вып-я

- Ключевые практики (?)

- Контроль и измерение

Всего СММ определяет следующий минимальный набор требований: реализовать18 ключевых областей процесса разработки ПО, содержащих 52 цели, 28 обязательств компании, 70 возможностей выполнения (гарантий компании) и 150 ключевых практик.



Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:  



double arrow
Сейчас читают про: