Карпенко с н введение в программную инженерию. Введение Программная инженерия (лекции). Из чего складывается стоимость ПО
Привет! Мне на почту поступил очень интересный вопрос.
Моя читательница столкнулась с проблемой установки старого жесткого диска с разъемом IDE
на новую материнскую плату, где установлены только контроллеры SATA
. И проблема даже не столько в необходимости использовать старый жесткий диск, сколько получить доступ к информации, которая хранилась на старом винчестере.
Необходимость подключить старый жесткий диск к компьютеру возникает у многих пользователей, поэтому я предлагаю свое решение.
Вот так выглядят SATA/IDE разъемы жестких дисков.
Конечно же эти разъемы не совместимы между собой. Разъем IDE подключается к материнской плате широким плоским шлейфом, а разъем SATA - тонким кабелем SATA.
Дело в том, что производители материнских плат стараются экономить на любых мелочах. Зачем устанавливать на плате устаревшие разъемы, если их уже почти никто не использует? Разъемы будут только занимать лишнее место и увеличивать стоимость материнской платы.
Кроме того предлагаю познакомится вот с этой статьей - самый дешевый способ подключить IDE устройство, которая также поможет вам решить вопрос.
Ищем решение!
Итак, мы можем поступить как НЕ профессионалы. Устанавлиавем старый IDE жесткий диск в другой компьютер с разъемами IDE, копируем с него всю нужную информацию на флешку или внешний жесткий диск, затем копируем всю информацию на новый компьютер. Прекрасно, информация спасена, но что нам делать со старым диском? Просто положить его на полку и забыть про него - это не наш метод.
Мы пойдем другим путем, поэтому для подключения IDE жесткого диска нам понадобится контроллер PCI - SATA/IDE.
Контроллеры могут отличаться друг от друга производителем, количеством разъемов, могут быть реализованы на разных чипах, но эти на различия не влияют на принцип работы с ними.
Вот так выглядит это чудо техники. И вот ссылка на похожий вариант для заказа из китая - http://aliexpress.com/pci-ide-sata (обратите внимание что контроллер по ссылке имеет разъем pci express-x1)
Стоимость такого контроллера составляет около 400-500 рублей. И он отрабатывает свою стоимость на 100%, так как взамен мы получаем возможность установки как старых ЖД на новые материнские платы, так и новые жесткие диски на старые материнские платы.
Данный контроллер имеет на борту несколько разъемов SATA и один контроллер IDE. Не стоит забывать, что к одному IDE контроллеру мы можем подключать 2 устройства, именно поэтому на IDE шлейфах есть разъемы для подключения сразу 2-х устройств.
Все, что нам нужно сделать это подключить контроллер PCI-SATA/IDE к материнской плате . Для этого нам нужно просто воткнуть его в разъем PCI материнской платы и зафиксировать болтиком.
После подключения разъема нам осталось только закрепить жесткий диск внутри корпуса и подключить к нему два провода (кабель данных и питание).
Таким образом мы получаем следующую схему подключения.
- подключаем контроллер к материнской плате;
- подключаем IDE шлейф к контроллеру;
- подключаем шлейф к жесткому диску;
- подключаем питание к диску;
Обратите внимание, что разъемы питания IDE жестких дисков и SATA также различаются. Обычно, на блоке питания компьютера и тех, и других разъемов хватает с запасом, но иногда для подключения SATA жестких дисков приходится использовать вот такой переходник molex (PATA) - SATA.
Если у вас недостаточно разъемов питания molex, используйте специальные разветвители.
После того, как мы разобрались с подключением, нам остается только включить компьютер и убедиться, что жесткий диск определился в системе. Для этого достаточно зайти в «Мой компьютер» и посмотреть ваши локальные диски. Помимо уже существующих должны добавиться локальные диски нового ЖД?
Также хочу обратить ваше внимание на то, что, хотя в комплекте и идет диск с драйверами
, данному контроллеру не нужна их установка
. Система сама найдет необходимые драйвера.
На последок добавлю еще один аргумент в пользу PCI-SATA/IDE контроллера . На жесткий диск, подключенный через такой контроллер можно спокойно устанавливать операционную систему, что неоднократно мной доказано.
Вот так это очень полезное устройство может облегчить нам жизнь.
Как всегда, оставляем свои впечатления, замечания, пожелания к статье в комментариях ниже. Я стараюсь ответить на каждый из них.
До встречи в следующем уроке, где я расскажу, как протестировать жесткий диск на битые блоки
.
PS. Надеюсь, многие читатели заметили, что на сайте немного изменился дизайн. Теперь он нравится мне еще больше! Хотелось бы узнать ваше мнение о новом дизайне сайта.
На данный момент самым распространенным интерфейсом является . SATA хоть и можно встретить в продаже, однако интерфейс уже считается устаревшим, к тому же уже начали поступать с .
Не стоит путать с SATA 3,0 Гбит/с, во втором случае речь идет об интерфейсе SATA 2, который имеет пропускную способность равную до 3,0 Гбит/с (у SATA 3 пропускная способность равна до 6 Гбит/с)
Интерфейс — устройство, передающее и преобразующее сигналы, от одного компонента оборудования к другому.
Виды интерфейса. PATA, SATA, SATA 2, SATA 3 и тд.
Накопители различных поколений использовали такие интерфейсы: IDE (ATA), USB, Serial ATA (SATA), SATA 2, SATA 3, SCSI, SAS, CF, EIDE, FireWire, SDIO и Fibre Channel.
IDE (АТА — Advanced Technology Attachment) — параллельный интерфейс подключения накопителей, именно поэтому был изменен (с выходом SATA ) на PATA (Parallel ATA). Раньше использовался для подключения винчестеров, но был вытеснен интерфейсом SATA. В настоящее время используется для подключения оптических накопителей.
SATA (Serial ATA) — последовательный интерфейс обмена данными с накопителями. Для подключения используется 8-pin разъем. Как и в случае с PATA – является устаревшим, и используется только для работы с оптическими накопителями. Стандарт SATA (SATA150) обеспечивал пропускную способность равную 150 МБ/с (1,2 Гбит/с).
SATA 2 (SATA300) . Стандарт SATA 2 увеличивал пропускную способность в двое, до 300 МБ/с (2,4 Гбит/с), и позволяет работать на частоте 3 ГГц. Стандартны SATA и SATA 2 совместимы между собой, однако для некоторых моделей необходимо вручную устанавливать режимы, переставляя джамперы.
Хотя про требованию спецификаций правильно называть SATA 6Gb/s . Этот стандарт в двое увеличил скорость передачи данных до 6 Гбит/с (600 МБ/с). Также к положительным нововведениям относится функция программного управления NCQ и команды для непрерывной передачи данных для процесса с высоким приоритетом.
Хоть интерфейс и был представлен в 2009 году, особой популярностью у производителей он пока не пользуется и в магазинах встречает не так часто. Кроме жестких дисков этот стандарт используется в SSD (твердотельные диски).
Стоит заметить, что на практике пропускная способность интерфейсов SATA не отличаются скоростью передачи данных. Практически скорость записи и чтения дисков не превышает 100 Мб/с. Увеличение показателей влияет только пропускную способность между контроллером и накопителя.
SCSI(Small Computer System Interface)
— стандарт применяется в серверах, где необходима повышеная скорость передачи данных.
SAS (Serial Attached SCSI)
— поколение пришедшее на смену стандарта SCSI, использующее последовательную передачу данных. Как и SCSI используется в рабочих станциях. Полностью совместив с интерефейсом SATA.
CF (Compact Flash)
— Интерфейс для подключения карт памяти, а также для 1,0 дюймовых винчестеров. Различают 2 стандарта: Compact Flash Type I и Compact Flash Type II, отличие в толщине.
FireWire – альтернативный интерфейс более медленному USB 2.0. Используется для подключения портативных . Поддерживает скорость до 400 Мб/с, однако физическая скорость ниже, чем у обычных. При чтении и записи максимальный порг 40 Мб/с.
Продолжаем самостоятельно собирать и апгрейдить свой ПК. И сегодня настала очередь выбора такого компонента, как жесткий диск для компьютера . Поговорим и о внутреннем HDD, который вставляется в корпус компьютера или ноутбука, и также о том, какой внешний жесткий диск выбрать, который можно было бы брать везде с собой и подключать при помощи USB.
Итак, жесткий диск компьютера (или HDD — Hard Disk Drive, винчестер, винт, хард) — это механическое устройство, на которое записывается вся информация — от операционной системы до ваших документов. Работает по тому же принципу, что и магнитная лента в старых аудио или видеокассетах — при помощи специальной магнитной головки информация записывается на специальные пластины, расположенные внутри герметично закрытого корпуса.
Давайте пройдемся по основным характеристикам хард-диска, а потом попробуем понять, как же все-таки его правильно выбрать для тех или иных задач и устройств.
Объем памяти
Итак, основной параметр — это емкость жесткого диска, то есть объем информации. который может на нем поместиться. Сейчас выпускаются диски от 128 Гб до 3 Тб, однако реально их объем немного меньше из-за особенностей переведения чисел из двоичной системы в десятиричную.
Интерфейс
Это тип разъема для соединения жесткого диска с материнской платой. До недавнего времени повсеместно был распространен интерфейс IDE (или ATA) — выглядит он в виде продолговатой розетки с множеством контактов и соединяется с системной платой при помощи плоского шлейфа.
Современные жесткие диски снабжаются одним из поколений разъема типа SATA (SATA, SATA 2 или SATA 3). При этом, SATA уже также сняли с производства и на современных устройствах можно встретить только взаимозаменяемое 2 и 3 поколение. Отличаются они скоростью передачи данных, поэтому если вставить диск SATA 3 в разъем SATA 2, то работать он будет со скоростью SATA 2.
- SATA — до 1,5 Гбит/с
- SATA 2 — до 3 Гбит/с
- SATA 3 — до 6 Гбит/с
Касательно интерфейса есть еще один нюанс. Жесткие диски для компьютера и ноутбука с разъемом SATA совместимы между собой, то есть если, допустим, сломался ноутбук и надо из него взять какие-то важные файлы, то можно достать из него хард, подключить SATA кабелем к настольному ПК и работать, как с обычным HDD. Если же на ноуте диск стандарта IDE, то подключить его через IDE шлейф к компу не получится — они несовместимы. Для этого нужно использовать специальный переходник.
Объем кэша
Еще одна характеристика, которая являет собой объем временного хранилища данных, используемого при работе харда. Чем он больше, тем быстрее будет обрабатываться информация, особенно это касается небольших по размеру файлов. Современные диски выпускаются с кэшем 16, 32 или 64 Мб.
Скорость вращения
Скорость вращения диска также влияет на скорость работы. Чем быстрее диски вращаются, тем информация обрабатывается быстрее. Измеряется она в количестве оборотов в минуту (RPM). В современных моделях используется следующая скорость:
- 5400/5900 — медленная, подходит для дисков, на которых будут размещаться архивные файлы большого объема
- 7200 — самая распространенная скорость, подойдет для решения большинства задач
- 10000 — максимальная производительность. Подойдет для установки игр или операционной системы
Форм-фактор
Размер имеет значения при выборе устройства, для которого вы приобретаете жесткий диск.
- Для настольного ПК — 3.5 дюйма
- Жесткий диск для ноутбука — 2.5 дюйма
Какой фирмы жесткий диск выбрать?
В настоящее время главными игроками на рынке являются Western Digital и Seagate. В отличие от других, продукция этих фирм зарекомендовала себя как наиболее надежная и качественная, моделей много, поэтому других не имеет смысла рассматривать вообще. Причем, большее доверие вызывает Western Digital из-за более объемной гарантии. Также они отличаются простотой выбора, так как все модели разделены на несколько групп по цветам их этикеток.
- Cover Blue — самая бюджетная и от этого не очень надежная серия. подойдут для повседневной работы, но не рекомендуются для хранения важных документов.
- Cover Green — малошумные, менее греющиеся и от этого медленные диски, подходящие для хранения данных.
- Cover Black — максимально производительные и надежные жесткие диски с двухядерными контроллерами.
- Cover Red — аналог черных, но отличаются еще более повышенной надежностью для хранения данных.
SSD накопитель как замена жесткому диску
Новое поколение накопителей информации называется твердотельный накопитель SSD (Solid State Drive). Его ошибочно иногда называют SSD жестким диском, хотя на самом деле никакого отношения к предыдущему поколению устройств оно не имеет, так как в нем уже нет механических частей — это чисто электронное устройство с микросхемами.
По сути, это скорее очень большая по объему и быстрая флешка. Из-за того, что в нем нет механики, SSD имеет очень высокую скорость работы и надежность. И как следствие, на данный момент очень высокую цену по сравнению с традиционным хардом. Кроме того, к преимуществам SSD перед HDD можно отнести бесшумность и меньшие потребности к энергопотреблению.
Параметры, определяющие их производительность, те же, что и HDD, только по понятным причинам отсутствует скорость вращения. Объем их от 32 до 960 Гб, интерфейс у всех самые последние — SATA 2, SATA 3 или PCI-E. Поскольку SATA не может обеспечить максимальной отдачи от использования дисков SSD, часто их снабжают разъемом PCI Express, что увеличивает скорость работы в 7 раз. Вставляется такой накопитель в слот PCI-E на материнской плате.
Скорость работы жёстких дисков и накопителей
Для сравнения скорости работы приведу скриншот, сделанный в программе тестирования скорости накопителей CrystalDiskMark. Как видно, HDD опережает только по скорости последовательной записи — это когда вы записываете на диск один файл очень большого объема. Согласитесь, делается это крайне редко, поэтому преимущества SSD налицо.
Происходит это из-за отсутствия механических частей — в нем нет крутящейся головки и вообще никакой механики — считывание информации происходит только на электронном уровне с микросхем, что значительно быстрее. Из-за отсутствия механических частей также твердотельный диск абсолютно нешумный и его невозможно повредить при падении, в отличие от HDD.
Недостатка же три — высокая стоимость, не такой большой срок службы и затруднительность восстановления с него данных при поломке. Это означает, что важные документы лучше все-таки хранить на традиционном жестком диске.
Поэтому при сборке производительного современного компьютера рекомендуется приобретать один SSD небольшого объема для установки на нем операционной системы и один жесткий диск (винт) большого объема для хранения остальной информации, например, Cover Red от Western Digital. Либо для экономии средств можно установить скоростной Cover Black небольшого объема для ОС и более медленный Cover Green большого объема для хранения документов.
Кстати, если вы все-таки решили остановить свой именно на SSD накопителе в качестве системного диска, то рекомендуется устанавливать на него систему не ниже Windows 7, так как во-первых, более старые не поддерживают этот тип тип накопителей, а во-вторых, в новых ОС оптимизирована работа с SSD для продления срока его службы.
Так как микросхемы SSD занимают меньше места (2.5″), часто в комплекте с ними идет переходник для установки в стандартный бокс для жесткого диска на корпусе ПК.
Внешний жесткий диск для ноутбука
Данный тип предназначен для мобильного перемещения файлов и отличается тем, что его не нужно размещать в корпусе компьютера или ноутбука. Он подключается при помощи одного из внешних разъемов — USB 2.0, USB 3.0, eSATA или FireWire. На сегодняшний день я бы рекомендовал приобретать USB 3.0, поскольку данный разъем не только уже повсеместно внедрен на современных материнских платах, но и совместим с предыдущим USB 2.0, а значит с ним удастся работать на любом компьютере.
Такие параметры, как объем кэша или скорость вращения здесь уже особой роли не играют, так как скорость передачи информации в данном случае будет зависеть от интерфейса подключения.
Форм-фактор отличает модели настольные от портативных переносных. Большие настольные диски чаще имеют также внешнее питание от электросети и их размер составляет 3.5″. Небольшие портативные жесткие диски удобнее для переноски, питаются непосредственно от порта USB и имеют размер 2.5″. Маленькие диски при этом менее скоростные.
Последнее, что можно сказать про выбор внешнего диска, это его защищенность. Поскольку тип устройства предполагает его перемещение, то желательно смотреть более ударозащищенные корпуса — с развитой резиновой внешней оболочкой. Либо просто приобрести дополнительно к нему отдельный чехол.
Также для внешнего подключении жестких дисков, предназначенных для установки внутрь, придумали специальные боксы-переходники, снабженные несколькими типичными внешними интерфейсами для подключения по кабелю. Диск вставляется в такой бокс и подключается к компьютеру, например, в порт USB.
Кроме того, многие дорогие современные корпусы уже имеют в верхней части специальный отсек для внешнего подключения обычного жесткого диска. если вам приходится часто их переставлять, то будет удобно.
На этом все, надеюсь мои советы вам помогут определиться с тем, какой выбрать жесткий диск для компьютера или ноутбука, а напоследок посмотрите еще три видео: про выбор дисков, про то, как правильно установить его в корпус ПК и про историю развития хард-дисков. Пока!
Технологии, модели и процессы создания ПО
Терминология Программное обеспечение (ПО) – компьютерные программы и соответствующая документация.
Разрабатывается по частному заказу или для продажи на рынке ПО.
Инженерия ПО – инженерная дисциплина, охватывающая все аспекты разработки ПО.
Системотехника (технология создания вычислительных систем) – дисциплина, охватывающая все аспекты создания и модернизации сложных вычислительных систем, где программное обеспечение играет ведущую роль. Сюда можно отнести технологии создания аппаратных средств, создание вычислительных процессов, развертывание всей системы, а также технологию создания непосредственно ПО.
Процесс создания ПО – совокупность процессов, приводящих к созданию программного продукта. Фундаментальные процессы, присущие любому проекту создания ПО:
- Разработка спецификации требований на ПО (Определяют функциональные характеристики системы и обязательны для выполнения).
- Создание программного обеспечения (создание ПО согласно спецификации).
- Аттестация ПО (Созданное ПО должно пройти аттестацию для подтверждения соответствию требованиям заказчика).
- Модернизация ПО (совершенствование ПО согласно измененным требованиям потребителя).
Модель процесса создания ПО – последовательность этапов, необходимых для разработки создаваемого ПО.
Рис. 1 – Распределения затрат при разработке ПО
Модели процесса разработки ПО:
1. Каскадная модель
2. Эволюционная модель
3. Формальное преобразование
4. Сборка программных продуктов из ранее созданных компонентов (модель сборки)
5. Итерационная (спиральная) модель
Методы создания ПО представляют собой структурный подход к созданию ПО, который способствует производству ПО эффективным, с экономической точки зрения, способом.
Все методы основаны на использовании моделей системы в качестве спецификации ее структуры:
1. Функционально-ориентированные (структурный анализ, JSD, 70-е годы) основаны на определении основных функциональных компонент системы.
2. Объектно-ориентированные (Booch, Rumbaugh) используют подходы, основанные на использовании унифицированного языка моделирования UML.
Computer-Aided Software Engineering– автоматизированная разработка ПО.
Процессы создания ПО Базовые процессы создания ПО:
Разработка спецификации. Проектирование и реализация. Аттестация.
Эволюция.
Жизненный цикл ПО – совокупность процессов, протекающих от момента принятия решения о создании ПО до его полного вывода из эксплуатации.
Разработка требований к ПО
Анализ осуществимости Разработка требований - это процесс, включающий мероприятия, необходимые для создания и
утверждения документа, содержащего спецификацию системных требований. Различают четыре основных этапа процесса разработки требований:
- анализ технической осуществимости создания системы,
- формирование и анализ требований,
- специфицирование требований и создание соответствующей документации,
- аттестация этих требований.
Рис. 13 – Процесс формирования требований
Анализ осуществимости должен осветить следующие вопросы:
1. Отвечает ли система общим и бизнес-целям организации-заказчика и организации-разработчика?
2. Можно ли реализовать систему, используя существующие на данный момент техно¬логии и не выходя за пределы заданной стоимости?
3. Можно ли объдинить систему с другими системами, которые уже эксплуатируются?
Выполнение анализа осуществимости включает сбор и анализ информации о будущей системе, написание соответствующего отчета. Например, эту информацию можно получить, ответив на следующие вопросы:
1. Что произойдет с организацией, если система не будет введена в эксплуатацию?
2. Какие текущие проблемы существуют в организации и как новая система поможет их решить?
3. Каким образом система будет способствовать целям бизнеса?
4. Требует ли разработка системы технологии, которая до этого не использовалась в организации?
После обработки собранной информации готовится отчет по анализу осуществимости создания системы.
На этапе формирования и анализа требований команда разработчиков ПО работает с заказчиком и конечными пользователями системы для выяснения области применения, описания системных сервисов, определения режимов работы системы и ее характеристик выполнения, аппаратных ограничений и т.д.
Процесс формирования и анализа требований достаточно сложен по ряду причин: На требования к системе могут влиять политические факторы.
Лица, участвующие в формировании требований, выражают в этих требованиях собственные точки зрения, основываясь на личном опыте работы.
Лица участвующие в формировании требований, имеют различные предпочтения и могут выражать их разными способами. Разработчики должны определить все потенциальные источники требований и выделить общие и противоречивые требования.
Экономическая и бизнес-обстановка, в которой происходит формирование требований, неизбежно будет меняться в ходе выполнения этого процесса.
Лица, участвующие в формировании требований, часто не знают конкретно, чего они хотят от компьютерной системы.
Рис. 14 – Процесс формирования и анализа требований
Процесс формирования и анализа требований проходит через ряд этапов:
Анализ предметной области. Аналитики должны изучить предметную область, где будет эксплуатироваться система.
Сбор требований. Это процесс взаимодействия с лицами, формирующими требования. Во время этого процесса продолжается анализ предметной области.
Классификация требований. На этом этапе бесформенный набор требований преобразуется в логически связанные группы требовании.
Разрешение противоречий. Без сомнения, требования многочисленных лиц, занятых в процессе формирования требований, будут противоречивыми. На этом этапе определяются и разрешаются противоречия такого рода. Назначение приоритетов. В любом наборе требований одни из них будут более важны, чем другие. На этом этапе совместно с лицами, формирующими требования, определяются наиболее важные требования. Проверка требований. На этом этапе определяется их полнота, последовательность и непротиворечивость. Распространены три подхода к формированию требований: метод, основанный на множестве опорных точек зрения ,сценарии иэтнографический метод.
Другие подходы, которые могут использоваться в процессе разработки требований, - это методы структурного анализа и методы прототипирования.
Не существует универсального подхода к формированию и анализу требований. Обычно для разработки требований одновременно используется несколько подходов.
Метод опорных точек зрения
Различные точки зрения на проблему позволяют увидеть ее с разных сторон. Однако эти взгляды не являются полностью независимыми и обычно перекрывают друг друга, а потому могут служить основой общих требований.
Подход с использованием различных опорных точек зрения к разработке требований признает эти точки зрения и использует их в качестве основы построения и организации как процесса формирования требований, так и непосредственно самих требований.
Различные методы предлагают разные трактовки выражения "точка зрения". Точки зрения можно трактовать следующим образом:
Как источник информации о системных данных. В этом случае на основе опорных точек зрения строится модель создания и использования данных в системе. В процессе формирования требований отбираются все такие точки зрения, на их основе определяются данные, которые будут созданы или использованы при работе системы, и способы обработки этих данных.
Как получатели системных сервисов. В этом случае точки зрения являются внешними (относительно системы) получателями системных сервисов. Точки зрения помогают определить данные, необходимые для выполнения системных сервисов или их управления.
Наиболее эффективным подходом к анализу интерактивных систем является использование внешних опорных точек зрения. Эти точки зрения взаимодействуют с системой, получая от нее сервисы и продуцируя данные и управляющие сигналы.
Этот тип точек зрения имеет ряд преимуществ:
Точки зрения, внешние к системе, - естественный способ структурирования процесса формирования требований.
Сравнительно просто решить, какие точки зрения следует оставить в качестве опорных: они должны отображать какой-либо способ взаимодействия с системой.
Данный подход полезен для создания нефункциональных требований, с которыми можно связать какой-либо сервис.
Этнографический подход
Этнографический подход к формированию системных требований используется для понимания и формирования социальных и организационных аспектов эксплуатации системы. Разработчик требований погружается в рабочую среду, где будет использоваться система. Его ежедневная работа связана с наблюдением и протоколированием реальных действий, выполняемых пользователями системы. Значение этнографического подхода заключается в том, что он помогает обнаружить неявные требования к системе, которые отражают реальные аспекты ее эксплуатации, а не формальные умозрительные процессы.
Этнографический подход позволяет детализировать требования для критических систем, чего не всегда можно добиться другими методами разработки требований. Однако, поскольку этот метод ориентирован на конечного пользователя, он не может охватить все требования предметной области и требования организационного характера.
Рис. 20 – Процесс разработки требований согласно этнографическому подходу
Во время процесса аттестации должны быть выполнены различные типы проверок документации требований:
1. Проверка правильности требований.
2. Проверка на непротиворечивость.
3. Проверка на полноту.
4. Проверка на выполнимость.
Существует ряд методов аттестации требований:
1. Обзор требований.
2. Прототипирование.
3. Генерация тестовых сценариев.
4. Автоматизированный анализ непротиворечивости.
Управление требованиями - это процесс управления изменениями системных требований. Процесс управления требованиями выполняется совместно с другими процессами разработки требований. Начало этого процесса планируется на то же время, когда начинается процесс первоначального формирования требований, непосредственно процесс управления требованиями должен начаться сразу после того, как черновая версия спецификации требований будет готова.
С точки зрения разработки требования можно разделить на два класса:
1. Постоянные требования.
2. Изменяемые требования.
Планирование управления требованиями
1. Идентификация требований.
2. Управление процессом внесения изменений.
3. Стратегия оперативного контроля.
- Информация об источнике требования
- Информация о требованиях
- Информация о структуре системы
4. Поддержка CASE-средств.
Процесс управления изменениями состоит из трех основных этапов:
1. Анализ проблем изменения спецификации.
2. Анализ изменений и расчет их стоимости.
3. Реализация изменений.
Определение | Пересмотренные |
||||||||
проблем в | |||||||||
требования |
|||||||||
требованиях | |||||||||
Анализ проблем | изменений и | Реализация | |||||||
изменение спецификации | расчет их | изменений | |||||||
стоимости | |||||||||
Рис. 21 – Процесс управления требованиями
Вопросы для обсуждения
1. Предложите, кто бы мог участвовать в формировании требований для университетской системы регистрации студентов.
2. Разрабатывается система ПО для автоматизации библиотечного каталога. Эта система будет содержать информацию относительно всех книг в библиотеке и будет полезна библиотечному персоналу, абонентам и читателям. Система должна иметь средства просмотра каталога, средства создания запросов и средства, позволяющие пользователям резервировать книги, находящиеся в данный момент на руках. Определите основные опорные точки зрения, которые необходимо учесть в спецификации системы.
3. Ваша компания использует стандартный метод анализа требований. В процессе работы вы обнаружили, что этот метод не учитывает социальные факторы, важные для системы, которую вы анализируете. Ваш руководитель дал вам ясно понять, какому методу анализа нужно следовать. Обсудите, что вы должны делать в такой ситуации.
Формальные спецификации
Так называемые формальные методы разработки программных систем широко не используются. Многие компании, разрабатывающие ПО, не считают экономически выгодным применение этих методов в процессе разработки.
Термин "формальные методы" подразумевает ряд операций, в состав которых входят создание формальной спецификации системы, анализ и доказательство спецификации, реализация системы на основе преобразования формальной спецификации в программы и верификация программ. Все эти действия зависят от формальной спецификации программного обеспечения. Формальная спецификация - это системная спецификация, записанная на языке, словарь, синтаксис и семантика которого определены формально. Необходимость формального определения языка предполагает, что этот язык основывается на математических концепциях. Здесь используется область математики, которая называется дискретной математикой и основывается на алгебре, теории множеств и алгебре логики.
В инженерии ПО определены три уровня спецификации программного обеспечения. Это пользовательские и системные требования и спецификация структуры программной системы. Пользовательские требования наиболее обобщенные, спецификация структуры наиболее детальна. Формальные математические спецификации находятся где-то между системными требованиями и спецификацией структуры. Они не содержат деталей реализации системы, но должны представлять ее полную математическую модель.
Разработка спецификация и проектирование могут выполняться параллельно, когда информация от этапов разработки спецификации передается к этапам проектирования и наоборот.
Рис. 22 – Процесс разработки формальной спецификации
Создание формальной спецификации требует детального анализа системы, который позволяет обнаружить ошибки и несоответствия в спецификации неформальных требований. Проблемы в требованиях, которые остаются необнаруженными до последних стадий процесса разработки ПО, обычно требуют больших затрат на исправление.
Существует два основных подхода к разработке формальной спецификации, которые используются для написания детализированных спецификаций нетривиальных программных систем.
1. Алгебраический подход, при котором система описывается в терминах операций и их отношений.
2. Подход, ориентированный на моделирование, при котором модель системы строится с использованием математических конструкций, таких, как множества и последовательности, а системные операции определяются тем, как они изменяют состояния системы.
Для разработки формальных спецификаций последовательных и параллельных систем в настоящее время создано несколько языков, представленных ниже в таблице.
Таблица 2 - Языки разработки формальных спецификаций
Большие системы обычно разбиваются на подсистемы, которые разрабатываются независимо друг от друга. Подсистемы могут использовать другие подсистемы, поэтому необходимой частью процесса специфицирования является определение интерфейсов подсистем. Если интерфейсы определены и согласованы, подсистемы можно разрабатывать независимо друг от друга.
Интерфейс подсистемы часто определяется как набор абстрактных типов данных и объектов, при этом только через интерфейс доступны описание данных и операции над ними. Поэтому спецификацию интерфейса подсистемы можно рассматривать как объединение спецификаций компонентов, что в итоге и составит описание интерфейса подсистемы.
Точные спецификации интерфейсов подсистем необходимы для разработчиков, которые пишут программный код, обращающийся к сервисам других подсистем. Спецификации интерфейсов содержат информацию о том, какие сервисы доступны в других подсистемах и как получить к ним доступ. Ясный и однозначный интерфейс подсистем уменьшает вероятность ошибок во взаимоотношениях между ними.
Алгебраический подход первоначально был разработан для описания интерфейсов абстрактных типов данных, где типы данных определяются скорее спецификациями операций над данными, чем способом представления самих данных. Это очень похоже на определение классов объектов. Алгебраический подход к формальным спецификациям определяет абстрактный тип данных в терминах операций над данными.
Структура спецификации объекта состоит из четырех компонентов:
Введение, где объявляется класс (sort) объектов. Класс - это общее название для множества объектов. Он обычно реализуется как тип данных. Введение может также включать объявление импорта (imports), где указываются имена спецификаций, определяющие другие классы. Импортирование спецификаций делает эти классы доступными для использования.
Описательная часть, в которой неформально описываются операции, ассоциированные с классом. Это делает формальную спецификацию более простой для понимания. Формальная спецификация дополняет это описание, обеспечивая однозначный синтаксис и семантику операций.
Часть сигнатур, в которой определяется синтаксис интерфейса объектного класса или абстрактного типа данных. Здесь описываются имена операций, количество и типы их параметров, а также классы выходных результатов операции.
Часть аксиом, где определяется семантика операций посредством создания ряда аксиом, которые характеризуют поведение абстрактного типа данных. Эти аксиомы связывают операции создания объектов класса с операциями, проверяющими их значения.
Рис. 23 - Структура алгебраической спецификации
Процесс разработки формальной спецификации интерфейса подсистемы включает следующие действия.
1. Структурирование спецификации. Представление неформальной спецификации интерфейса в виде множества абстрактных типов данных или объектных классов. Также неформально определяются операции, ассоциированные с каждым классом.
2. Именование спецификаций. Задаются имена для каждой спецификации абстрактного типа, определяются параметры спецификаций (если они необходимы) и имена определяемых классов.
3. Определение операций. На основании списка выполняемых интерфейсом функций для каждой спецификации определяется связанный с ней набор операций. Необходимо предусмотреть операции по созданию экземпляров классов, по изменению значений экземпляров классов и по проверке этих значений. Вероятно, придется добавить новые функции к первоначально определенному списку функций интерфейса.
4. Неформальная спецификация операций. Написание неформальной спецификации для каждой операции, где должно быть указано, как операции воздействуют на определяемый класс.
5. Определение синтаксиса операций. Определение синтаксиса и параметров для каждой операции. Это часть сигнатуры формальной спецификации.
6. Определение аксиом. Определение семантики операций путем описания условий, которые должны
выполняться для различных комбинаций операций.
Операции над абстрактным типом данных обычно относятся к одному из двух классов.
1. Операции конструирования, которые создают или изменяют объекты класса. Обычно их называют Create (Создать), Update (Изменить), Add (Добавить) или Cons (Конструирование).
2. Операции проверки, которые возвращают атрибуты класса. Обычно им дают имена, соответствующие именам атрибута, или имена, подобные Eval (Значение), Get (Получить) и т.п.
Хорошим эмпирическим правилом для написания алгебраической спецификации является создание аксиом для каждой операции конструирования с применением всех операций проверки. Это означает, что если есть m операций конструирования и n операций проверки, то должно быть определено m x n аксиом.
Операции конструирования, связанные с абстрактным типом данных, часто очень сложны и могут определяться через другие операции конструирования и проверки. Если операции конструирования определены посредством других операций, то необходимо определить операции проверки, используя более примитивные конструкции.
В спецификации списка операциями конструирования являются Create, Cons и Tail, которые создают списки. Операциями проверки являются Head и Length, которые используются для получения значений атрибутов списка. Операция Tail не является примитивной конструкцией, поэтому для нее можно не определять аксиомы с использованием операций Head и Length, но в таком случае Tail необходимо определить посредством примитивных конструкций.
При написании алгебраических спецификаций часто используется рекурсия. Результат операции Tail - список, сформированный из входного списка путем удаления верхнего элемента. Это определение подсказывает, как использовать рекурсию для построения данной операции. Операция определяется на пустых списках, затем рекурсивно переходит на непустые списки и завершается, когда результатом снова будет пустой список.
Иногда проще понять рекурсивные преобразования, используя короткий пример. Предположим, что есть список , где элемент 5 - начало (вершина) списка, а элемент 7- конец списка. Операция Cons(, 9) должна возвратить список , а операция Tail, примененная к этому списку, должна возвратить список . Приведем последовательность рекурсивных преобразований, приводящую к этому результату.
Tail () =
Tail (Cons (, 9)) =
Cons (Tail (), 9) =
Cons (Tail (Cons (, 7)), 9) =
Cons (Cons (Tail (), 7), 9) =
= Cons (Cons (Tail (Cons (, 5)), 7), 9) =
= Cons (Cons (, 7), 9) =
Cons (, 9) =
Здесь систематически использовались аксиомы для Tail, что привело к ожидаемому результату. Аксиому для операции Head можно проверить подобным способом.
Простые алгебраические методы подходят для описания интерфейсов, когда операции, ассоциированные с объектом, не зависят от состояния объекта. Тогда результаты любой операции не зависят от результатов предыдущих операций. Если это условие не выполняется, алгебраические методы могут стать громоздкими.
Более того, я думаю, что алгебраические описания поведения систем часто искусственны и трудны для понимания.
Альтернативным подходом к созданию формальных спецификаций, который широко используется в программных проектах, является спецификация, основанная на моделях системы. Такие спецификации используют модели состояний системы. Системные операции определяются посредством изменений состояний системной модели. Таким образом определяется поведение системы.
Вопросы для обсуждения
1. Перед вами поставлена задача "продажи" методов формальной спецификации организации, разрабатывающей программное обеспечение. Как вы будете объяснять преимущества формальной спецификации скептически настроенным разработчикам ПО?
2. Объясните, почему необходимо определять интерфейсы подсистем как можно точнее и почему алгебраическая спецификация наиболее подходит для специфицирования интерфейсов подсистем.
3. Абстрактный тип данных, представляющий стек, имеет следующие операции:
a. New (Создать) - создает пустой стек;
b. Push (Добавить) - добавляет элемент в вершину стека;
c. Тор (Вершина) - возвращает элемент на вершине стека;
d. Retract (Удалить) - удаляет элемент из вершины стека и возвращает модифицированный стек;
e. Empty (Пустой) - возвращает значение истины, если стек пустой.
Определите этот абстрактный тип данных, используя алгебраическую спецификацию.
4. Вы системный инженер и вас просят назвать наилучший способ разработки программного обеспечения для сердечного стимулятора, критического по обеспечению безопасности. Вы предлагаете разработать формальную спецификацию системы, но ваше предложение отвергнуто менеджером. Вы считаете, что его доводы не обоснованы и базируются на предубеждениях. Будет ли этичной разработка системы с использованием методов, которые вы считаете неподходящими?
Модели систем
Одной из широко используемых методик документирования системных требований является построение ряда моделей системы. Эти модели используют графические представления, показывающие решение как исходной задачи, для которой создается система, так и разрабатываемой системы. Модели являются связующим звеном между процессом анализа исходной задачи и процессом проектирования системы.
Модели могут представить систему в различных аспектах:
Внешнее представление, когда моделируется окружение или рабочая среда системы. Описание поведения системы, когда моделируется ее поведение.
Описание структуры системы, когда моделируется системная архитектура или структуры данных, обрабатываемых системой.
Наиболее важным аспектом системного моделирования является то, что оно опускает детали. Модель является абстракцией системы и легче поддается анализу, чем любое другое представление этой системы. В идеале представление системы должно сохранять всю информацию относительно представляемого объекта.Абстракция является упрощением и определяется выбором наиболее важных характеристик системы.
Типы системных моделей, которые могут создаваться в процессе анализа систем:
Модель обработки данных. Диаграммы потоков данных показывают последовательность обработки данных в системе.
Композиционная модель. Диаграммы "сущность-связь" показывают, как системные сущности составляются из других сущностей.
Архитектурная модель. Эти модели показывают основные подсистемы, из которых строится система. Классификационная модель. Диаграммы наследования классов показывают, какие объекты имеют общие характеристики.
Модель "стимул-ответ". Диаграммы изменения состояний показывают, как система реагирует на внутренние и внешние события.
Модели системного окружения
При анализе будущей системы необходимо определить границы между системой и ее окружением, специфицировать само рабочее окружение и связи между ним и системой. Обычно на этом этапе строится простая структурная модель.
Структурные модели высокого уровня обычно являются простыми блок-схемами, где каждая подсистема представлена именованным прямоугольником, а линии показывают, что существуют некоторые связи между подсистемами.
Рис. 24 – Пример модели окружения
Простые структурные модели обычно дополняются моделями других типов, например моделями процессов , которые показывают взаимодействия в системе, илимоделями потоков данных , которые показывают последовательность обработки и перемещения данных внутри системы и между другими системами в окружающей среде.
Рис. 25 - Модель процесса приобретения оборудования
Поведенческие модели Эти модели используются для описания общего поведения системы. Обычно рассматривают два типа
поведенческих моделей - модель потоков данныхи модель конечного автомата. Эти модели можно использовать отдельно или совместно, в зависимости от типа разрабатываемой системы.
Модели потока данных - это интуитивно понятный способ показа последовательности обработки данных внутри системы. Нотации, используемые в этих моделях, описывают обработку данных с помощью системных функций, а также хранение и перемещения данных между системными функциями.
В диаграммах потоков данных используются следующие обозначения: закругленные прямоугольники соответствуют этапам обработки данных; стрелки, снабженные примечаниями с названием данных, представляют потоки данных; прямоугольники соответствуют хранилищам или источникам данных.
Рис. 26 – Модель потоков данных
Модели потоков данных показывают функциональную структуру системы, где каждое преобразование данных соответствует одной системной функции. Иногда модели потоков данных используют для описания потоков данных в рабочем окружении системы. Такая модель показывает, как различные системы и подсистемы обмениваются информацией. Подсистемы окружения не обязаны быть простыми функциями.
Рис. 27 - Диаграмма потоков данных комплекса CASE-средств
Модели конечных автоматов используются для моделирования поведения системы, реагирующей на внутренние или внешние события. Такая модель показывает состояние системы и события, которые служат причиной перехода системы из одного состояния в другое.
Модели конечных автоматов являются неотъемлемой частью методов проектирования систем реального времени. Такие модели определяются диаграммами состояний , которые стали основой системы нотаций в языке моделирования UML.
Главная > ДокументВведение в программную инженерию
Программная инженерия: назначение, основные принципы и понятия
1.1Предпосылки и история
В конце 60-х – начале 70-х годов прошлого века произошло событие, которое вошло в историю как первый кризис программирования. Событие состояло в том, что стоимость программного обеспечения стала приближаться к стоимости аппаратуры («железа»), а динамика роста этих стоимостей позволяла прогнозировать, что к середине 90-годов все человечество будет заниматься разработкой программ для компьютеров. Тогда и заговорили о программной инженерии (или технологии программирования, как это называлось в России) как о некоторой дисциплине, целью которой является сокращение стоимости программ.
С тех пор программная инженерия прошла достаточно бурное развитие. Этапы развития программной инженерии можно выделять по-разному. Каждый этап связан с появлением (или осознанием) очередной проблемы и нахождением путей и способов решения этой проблемы. На слайде представлены ряд фундаментальных проблем разработки программ и найденных фундаментальных методов их решения. Эти методы и по сей день составляют основу подходов к проектированию программных продуктов.
Повторное использование кода (модульное программирование)
Проблема . На первых этапах становления программной инженерии (даже когда она так еще не называлась) было отмечено, что высокая стоимость программ связана с разработкой одинаковых (или похожих) фрагментов кода в различных программах. Вызвано это было тем, что в различных программах как части этих программ решались одинаковые (или похожие) задачи: решение нелинейных уравнений, расчет заработной платы, … Использование при создании новых программ ранее написанных фрагментов сулило существенное снижение сроков и стоимости разработки.
Модульное программирование . Главный принцип модульного программирования состоял в выделении таких фрагментов и оформлении их в виде модулей. Каждый модуль снабжался описанием, в котором устанавливались правила его использования – интерфейс модуля. Интерфейс задавал связи модуля с основной программой – связи по данным и связи по управлению. При этом возможность повторного использования модулей определялась количеством и сложностью этих связей, или насколько эти связи удалось согласовывать с организацией данных и управления основной программы. Наиболее простыми в этом отношении оказались модули решения математических задач: решения уравнений, систем уравнений, задач оптимизации. К настоящему времени накоплены и успешно используются большие библиотеки таких модулей.
Для многих других типов модулей возможность их повторного использования оказалась проблематичной в виду сложности их связей с основной программой. Например, модуль расчета зарплаты, написанный для одной фирмы, может не подойти для другой, т.к. зарплата в этих фирмах рассчитывается не во всем одинаково. Повторное использование модулей со сложными интерфейсами является достаточно актуальной и по сей день. Для ее решения разрабатываются специальные формы (структуры) представления модулей и организации их интерфейсов.
Рост сложности программ (структурное программирование)
Проблема . Следующий этап возрастания стоимости ПО был связан с переходом от разработки относительно простых программ к разработке сложных программных комплексов. К числу таких сложных программ относятся: системы управления космическими объектами, управления оборонным комплексом, автоматизации крупного финансового учреждения и т.д. Сложность таких комплексов оценивалась следующими показателями:
Большой объем кода (миллионы строк)
Большое количество связей между элементами кода
Большое количество разработчиков (сотни человек)
Большое количество пользователей (сотни и тысячи)
Длительное время использования
Для таких сложных программ оказалось, что основная часть их стоимости приходится не на создание программ, а на их внедрение и эксплуатацию. По аналогии с промышленной технологией стали говорить о жизненном цикле программного продукта, как о последовательности определенных этапов: этапа проектирования, разработки, тестирования, внедрения и сопровождения.
Структурное программирование . Этап сопровождения программного комплекса включал действия по исправлению ошибок в работе программы и внесению изменений в соответствии с изменившимися требованиями пользователей. Основная причина высокой стоимости (а порой и невозможности выполнения) этапа сопровождения состояла в том, что программы были плохо спроектированы – документация была не понятна и не соответствовала программному коду, а сам программный код был очень сложен и запутан. Нужна технология, которая обеспечит «правильное» проектирование и кодирование. Основные принципы технологии структурного проектирования и кодирования:
Нисходящее функциональное проектирование, при котором в системе выделяются основные функциональные подсистемы, которые потом разбиваются на подсистемы и т.д. (принцип «разделяй и властвую»)
Применение специальных языков проектирования и средств автоматизации использования этих языков
Дисциплина проектирования и разработки: планирование и документирование проекта, поддержка соответствие кода проектной документации
Структурное кодирование без goto
Модификация программ (ООП)
Проблема . Следующая проблема роста стоимости программ была вызвана тем, что изменение требований к программе стали возникать не только на стадии сопровождения, но и на стадии проектирования – проблема заказчика, который не знает, что он хочет. Создание программного продукта превратилось в его перманентное перепроектирование. Возник вопрос как проектировать и писать программы, чтобы обеспечить возможность внесений изменений в программу, не меняя ранее написанного кода.
Объектно-ориентированное программирование . Решением этой проблемы стало использование подхода или метода, который стали называть объектно-ориентированным проектированием и программированием. Суть подхода состоит в том, что вводится понятие класса как развитие понятия модуля с определенными свойствами и поведением, характеризующими обязанностями класса. Каждый класс может порождать объекты – экземпляры данного класса. При этом работают основные принципы (парадигмы) ООП:
Инкапсуляция – объединение в классе данных (свойств) и методов (процедур обработки).
Наследование – возможность вывода нового класса из старого с частичным изменением свойств и методов
Полиморфизм – определение свойств и методов объекта по контексту
Проиллюстрировать возможности принципов ООП можно на следующем примере. В организации, состоящей из трех отделов надо начислять заработную плату. В программе каждый отдел представлен своим модулем – объектом, а начисление зарплаты – объектом «Зарплата». При необходимости расчета зарплаты объекту «Отдел» передается экземпляр объекта «Зарплата». Объект «Отдел» передает объекту «Зарплата» необходимые данные и затем с помощью методов объекта «Зарплата» выполняет необходимые расчеты.
В отделе 3 частично изменились правила начисления зарплаты. В этой ситуации при объектно-ориентированном подходе из класса «Зарплата» выводится класс «Зарплата 1», который наследует неизменившиеся правила начисления зарплаты и переопределяет изменившиеся. Здесь при расчете зарплаты объектам «Отдел 1» и «Отдел 2» будет передаваться объект «Зарплата», а объекту «Отдел 3» - объект «Зарплата 1». При таких изменениях:
Срабатывает принцип наследования: код «Зарплата», «Отдел 1» и «Отдел 2» остаются без изменения, а код «Зарплата 1» изменяется ровно настолько, насколько это необходимо.
Срабатывает принцип полиморфизма: код «Отдел 3» также не изменяется – он продолжает считать, что работает с объектом «Зарплата»
Некоторые итоги
Программная инженерия (или технология программирования) как некоторое направление возникло и формировалось под давлением роста стоимости создаваемого программного обеспечения. Главная цель этой области знаний - сокращение стоимости и сроков разработки программ.
Программная инженерия прошла несколько этапов развития, в процессе которых были сформулированы фундаментальные принципы и методы разработки программных продуктов. Основной принцип программной инженерии состоит в том, что программы создаются в результате выполнения нескольких взаимосвязанных этапов (анализ требований, проектирование, разработка, внедрение, сопровождение), составляющих жизненный цикл программного продукта. Фундаментальными методами проектирования и разработки являются модульное, структурное и объектно-ориентированное проектирование и программирование.
Продолжение кризиса программирования
Несмотря на то, что программная инженерия достигла определенных успехов, перманентный кризис программирования продолжается. Связано это с тем, рубеж 80–90-х годов отмечается как начало информационно-технологической революции, вызванной взрывным ростом использования информационных средств: персональный компьютер, локальные и глобальные вычислительные сети, мобильная связь, электронная почту, Internet и т.д.
Цена успеха – кризис программирования принимает хронические формы:
- США тратит ежегодно более $200 млрд. на более чем 170 тыс. проектов разработки ПО в сфере IT; 31,1% из них закрываются, так и не завершившись; 52,7% проектов завершаются с превышением первоначальных оценок бюджета/сроков и ограниченной функциональностью; потери от недополученного эффекта внедрения ПО измеряются триллионами.
Статистика по 30,000 проектам по разработке ПО в американских компаниях показывает следующее распределение между:
У спешными – вовремя и в рамках бюджета был выполнен весь намеченный фронт работ
Проблемными – нарушение сроков, перерасход бюджета и/или сделали не все, что требовалось
Проваленными – не были доведены до конца из-за перерасхода средств, бюджета, качества.
Источник: The Standish Group International The Standish Group International, Inc., Extreme Chaos, 2000 - //sample_research/PDFpages/extreme_chaos.pdf
1.2Программная инженерия – что это такое?
Начнем с определений
На сегодняшний день нет единого определения понятия «программная инженерия». На слайде приведено несколько таких определений, данных крупными специалистами в этой области, или зафиксированные в документах ведущих организаций.
Сам термин – software engineering (программная инженерия) - впервые был озвучен в октябре 1968 года на конференции подкомитета НАТО по науке и технике (г.Гармиш, Германия). Присутствовало 50 профессиональных разработчиков ПО из 11 стран. Рассматривались проблемы проектирования, разработки, распространения и поддержки программ. Там впервые и прозвучал термин «программная инженерия» как некоторая дисциплина, которую надо создавать и которой надо руководствоваться в решении перечисленных проблем.
Вскоре после этого в Лондоне состоялась встреча 22-х руководителей проектов по разработке ПО. На встрече анализировались проблемы и перспективы развития ПО. Отмечалась возрастающее воздействие ПО на жизнь людей. Впервые серьезно заговорили о надвигающемся кризисе ПО. Применяющиеся принципы и методы разработки ПО требовали постоянного усовершенствования. Именно на этой встрече была предложена концепция жизненного цикла ПО (SLC – Software Lifetime Cycle) как последовательности шагов-стадий, которые необходимо выполнить в процессе создания и эксплуатации ПО. Вокруг этой концепции было много споров. В 1970 г. У.У. Ройс (W.W. Royce) произвел идентификацию нескольких стадий в типичном цикле и было высказано предположение, что контроль выполнения стадий приведет к повышению качества ПО и сокращению стоимости разработки.
Разберемся в вопросах
Для того, чтобы получить представление о том, что такое программная инженерия, попробуем разобраться в следующих вопросах:
- Что такое программное обеспечение (software)? Что такое программная инженерия? В чем разница между программной инженерией (software engineering) и информатикой (computer science)? В чем разница между программной инженерией и системной инженерией (systems engineering)? В чем отличие программной инженерии от других инженерий?
Что такое программное обеспечение (software)?
Программное обеспечение это набор компьютерных программ, процедур и связанной с ними документации и данных (ISO/IEC 12207). Взгляд на ПО как только на программу, сидящую в компьютере слишком узок. Дело в том, что продается (поставляется) не только программа, но еще и документация, в которой можно прочитать как установить программу и как ей пользоваться и данные для установки программы в различных условиях (конфигурационные файлы). Поэтому ПО иногда называют программным продуктом. Т.е. программный продукт (программное обеспечение) – это не только программы, а также вся связанная с ними документация и конфигурационные данные, необходимые для корректной работы программы. А специалисты по программному обеспечению разрабатывают программные продукты, т.е. такое ПО, которое может быть продано потребителю.
В зависимости от того, для кого разрабатываются программные продукты (конкретного заказчика или рынка, программные продукты бывают двух типов:
- коробочные продукты (generic products – общие продукты или shrink-wrapped software – упакованное ПО) заказные продукты (bespoke – сделанный на заказ или customized products – настроенный продукт). Важная разница между ними заключается в том, кто ставит задачу (определяет, или специфицирует требования). В первом случае это делают сами разработчики на основе анализа рынка (маркетинга) – и при этом рискуют сами. Во втором – заказчик и при этом рискует, что разработчик не сможет реально выполнить все требования в срок и при выделенном бюджете.
Что такое программная инженерия?
Инженерная дисциплина
Все аспекты производства ПО
Для решения задачи инженеры применяют теории, методы и средства, пригодные для решения данной задачи, но они применяют их выборочно и всегда пытаются найти решения, даже в тех случаях, когда теорий или методов, соответствующих данной задаче, еще не существует. В этом случае инженер ищет метод или средство для решения задачи, применяет его и несет ответственность за результат – ведь метод или средство еще не проверены. Набор таких инженерных методов или способов, теоретически возможно не обоснованных, но получивших неоднократное подтверждение на практике, играет большую практическую роль. В программной инженерии они получили название лучших практик (best practices).
Инженеры работают в условиях ограниченных ресурсов: временных, финансовых и организационных (оборудование, техника, люди). Иными словами, продукт должен быть создан в установленные сроки, в рамках выделенных средств, оборудования и людей. Хотя это в первую очередь относится к созданию заказных продуктов (оговаривается в условиях контракта), но при создании коробочных продуктов эти ограничения имеют не меньшее значение, т.к. здесь они диктуются условиями рыночной конкуренции.
Все аспекты производства ПО . Программная инженерия занимается не только техническими вопросами производства ПО (специфицирование требований, проектирование, кодирование,…), но и управлением программными проектами, включая вопросы планирования, финансирования, управления коллективом и т.д. Кроме того, задачей программной инженерии является разработка средств, методов и теорий для поддержки процесса производства ПО.
Программные инженеры применяют систематичные и организованные подходы к работе для достижения максимальной эффективности и качества ПО. Их задача состоит в адаптации существующих методов и подходов к решению свой конкретной проблемы.
В чем отличия от информатики?
И наконец, информатика – это не единственный теоретический фундамент программной инженерии, т.к. круг проблем, стоящих перед программным инженером значительно шире просто написания программ. Это еще управление финансами, организация работ в коллективе, взаимодействие с заказчиком и т.д. Решение этих проблем требуют фундаментальных знаний, выходящих за рамки информатики.
В чем отличие от других инженерий?
Отличие программной инженерии от других инженерий интересно прежде всего с точки зрения двух вопросов:
Почему доля провальных проектов в программной инженерии так велика по сравнению с другими инженериями?
Можно ли в программной инженерии применять опыт других инженерий?
Эти вопросы является фундаментальными для программной инженерии. По этому поводу высказывается много мнений (и часто противоположных). Остановимся на некоторых более или менее очевидных отличиях программной инженерии от других инженерий.
Прежде всего, отметим, что жизненный цикл продукта любой инженерии в упрощенном виде включает фазы: проектирование, создание образца, испытание, производство, эксплуатация.
Компьютерная программа – это (в отличие от объектов других инженерий) не материальный объект (просьба не путать с носителем программы – устройством памяти любого типа). Отсюда следуют следующие отличия. Фаза производства состоит в копировании образца на другие носители. Стоимость фазы исчезающее мала. Если кодирование считать элементом проектирования (что очень близко к истине), то отсутствует также и фаза создания образца (строится компилятором и линковщиком)
Отсюда следуют следующие выводы:
Стоимость программы – это стоимость только ее проектирования
Стоимость проектирования коробочных продуктов «размазывается» по копиям
Стоимость заказных продуктов (массово не копируемых) остается высокой
В чем еще отличие от других инженерий?
Второе существенное отличие состоит в том, что программа – искусственный объект. Т.е. для программы нет объективных законов, которым бы подчинялось ее поведение. Например, у инженера – строителя есть объективные законы строительной механики: равновесия моментов и сил, устойчивости механических систем и т.д. Инженер – строитель может проверить свои архитектурные решения на соответствие этим законам и тем самым обеспечить удачу проекта. Эти законы объективны, они будут действовать всегда. У программного инженера на первый взгляд также есть типовые, проверенные временем архитектурные решения (например, клиент-серверная архитектура). Но эти решения определяются уровнем развития вычислительной техники (и адекватным им уровнем требований). С появлением техники с принципиально новыми возможностями программному инженеру придется искать новые решения.
Прямым следствием отсутствия возможности «теоретического» контроля проекта является то, что тестирование продукта – это единственный способ убедиться в его качестве. Именно поэтому стоимость тестирования составляет существенную стоимость ПО. Кстати, строительный инженер, как правило, лишен возможности такого «тестирования» своего продукта перед сдачей его в эксплуатацию.
Ну и наконец, программная инженерия – молодая дисциплина, опыт которой насчитывает всего несколько десятков лет. По сравнению с опытом строительной инженерии (тысячелетия) это конечно очень мало. Программную инженерию иногда сравнивают с ранней строительной, когда законы строительной механики еще не были известны и строительные инженеры действовали методом проб и ошибок, накапливая бесценный опыт. Несмотря на молодой возраст, программная инженерия также накопила определенный опыт, который позволяет (при разумном его применении) делать удачные проекты. Этот опыт выражен в основных принципах программной инженерии, которые мы с вами сейчас рассмотрим.
Подробнее о проблемах проектирования ПО можно посмотреть в неоднозначной статье Кони Бюрера «От ремесла к науке: поиск основных принципов разработки ПО» /fset.asp?Url=/rational/science.htm
Из чего складывается стоимость ПО?
Структура стоимости ПО существенно зависит от типа ПО, применяемых методов его разработки и … метода оценки. Так, многие авторы отмечают высокую долю стоимости этапа сопровождения. Для некоторых типов ПО она может составлять 60 и более процентов от общей стоимости. Между тем, этап сопровождения включает выполнение двух видов работ: исправление ошибок в программе (несоответствий первоначальным требованиям) и внесение изменений в программу (добавление новых требований). При другом подходе к оценке можно считать, что этап сопровождения на стоит оценивать отдельно, т.к. исправление ошибок можно отнести к продолжению тестирования, а внесение изменений – к новому проекту.
Типовое распределение стоимости между основными этапами (без сопровождения) выглядит следующим образом:
15% - спецификация – формулировка требований и условий разработки
25% - проектирование – разработка и верификация проекта
20% - разработка – кодирование и тестирование компонент
40% - интеграция и тестирование – объединение и сборочное тестирование продукта
Отклонения от этой схемы в зависимости от типа ПО выглядят следующим образом:
Для коробочного ПО характерна более высокая доля тестирования за счет сокращения прежде всего доли спецификации (до 5%)
Распределение стоимости заказного ПО зависит от его сложности. При сложном ПО также возрастает доля интеграции и тестирования, но за счет сокращения доли проектирования и разработки Доля спецификаций может возрастать. Сокращение доли проектирования и разработки достигается за счет применения опробованных проектных решений и повторного использования готовых компонент.
Применение опробованных решений и готовых компонент при создании коробочных продуктов позволяет повысить качество и сократить сроки разработки.
Еще вопросы
Для того, чтобы получить представление о том, в чем состоит накопленный программной инженерией опыт, попробуем разобраться в следующих вопросах:
Что такое программный процесс?
Что такое модель программного процесса?
Что такое методы программной инженерии?
Что такое CASE (Computer-Aided Software Engineering)?
Какими свойствами обладает хорошая программа?
Какие основные трудности стоят перед программной инженерией?
Программный процесс?
Одним из основных понятий программной инженерии является понятие жизненного цикла программного продукта и программного процесса.
Жизненный цикл – непрерывный процесс, начинающийся с момента принятия решения о создании ПО и заканчивающийся снятием его с эксплуатации. Жизненный цикл разбивается на отдельные процессы.
Процесс – совокупность действий и задач, имеющих целью достижение значимого результата. Основными процессами (иногда называют этапами или фазами) жизненного цикла являются:
Разработка спецификации требований (результат – описания требований к программе, которые обязательны для выполнения – описание того, что программа должна делать)
Разработка проекта программы (результат – описание того, как программа будет работать)
Кодирование (результат – исходный код и файлы конфигурации)
Тестирование программы (результат - контроль соответствия программы требованиям)
Документирование (результат – документация к программе)
Кроме основных, существует много дополнительных и вспомогательных процессов, связанных не созданием продукта, а с организацией работ (нефункциональные процессы): создание инфраструктуры, управление конфигурацией, управление качеством, обучение, разрешение противоречий, …
Процесс должен быть установлен. Полное установление процесса предполагает:
- Описание процесса – детальное описание действий и операций процесса Обучение процессу – проведение занятий с персоналом по освоению процесса Введение метрик – установление количественных показателей хода выполнения Контроль выполнения – измерение метрических показателей и оценка хода выполнения Усовершенствование – изменение процесса при меняющихся условиях применения
Применение полных (тяжелых) процессов требует дополнительных ресурсов (зачастую существенных) и далеко не всегда окупается полученным результатом. Поэтому, выбор состава процессов, степени их установленности (полноты установленности) в каждом конкретном случае может быть сделан по-разному в соответствии с выбранной моделью процесса.