2. Введение в инжинерное программирование
|
|
2.1. Цели и задачи инженерного программирования
Программное обеспечение - этото совокупность программ, процедур работы и соответствующей документации для вычислительной системы(ВС).
Инженерное программирование - это такое применение естественных и математических наук, в результате которого потенциальные возможности ЭВМ реализуются на пользу человеку с помощью машинных программ, организационных процедур и соответствующей
документации.
Стоимость и качество производимого ПО определяются уровнем развития инженерного программирования. Важность инженерного программирования обуславливается следующими двумя тенденциями:
- ПО является сложным изделием и стоимость его все более возрастает;
- ПО оказывает значительное и все возрастающее воздействие на общественное благосостояние.
Стоимость ПО, разработанного в США, характеризуется следующими данными.
Табл.2.1.Стоимость ПО в США
-------------------T-------------------------------------------------¬
¦ ¦ Стоимость ПО ¦
¦ Годы +----------------------T--------------------------+
¦ ¦ млрд $ ¦ %% ВНП ¦
+------------------+----------------------+--------------------------+
¦ ¦ ¦ ¦
¦ 1980 ¦ 40 ¦ 2,0 ¦
¦ ¦ ¦ ¦
¦ 1985 ¦ 190 ¦ 8,5 ¦
¦ ¦ ¦ ¦
¦ 1990 ¦ 297 ¦ 13,0 ¦
L------------------+----------------------+---------------------------
Общемировые тенденции роста стоимости ПО можно проиллюстрировать тем, что стоимость ПО по сравнению со стоимостью технических средств вычислительной техники имеет более высокий темп роста (рис.2.1)
Западноевропейская оценка
Доля пол- 100 --------------------------- .................
ной стои- | | .......|........ .. ..
мости, %% | ТС | .... | .. .. ..
| ..|. | .. .. .. ..
| .. | | .. ..
50 |------------|------------| Японская оценка
| . | |
| . | |
| ... | ПО |
|.. | |
0 -------------------------- 1955 1970 1985
Рис.2.1.Тенденции изменения стоимости ТС и ПО
Подобный рост спроса на ПО предъявляет существенные требования к инженерному программированию:
- существенно повысить производительность труда при разработке ПО;
- повысить эффективность сопровождения ПО, так как оно составляет около половины стоимости ПО (рис.2.1).
Рост спроса на ПО является следствием того, что автоматизация труда человека с помощью ЭВМ становится все более и более выгодной. Эта тенденция может быть подтверждена следующими данными. В настоящее время в США более половины работающих используют ЭВМ в своей профессиональной деятельности, не обязательно зная как функционируют ТС и ПО.
То есть, они неявно полагались на правильность результатов применения ПО. Еще более глубокое воздействие ЭВМ и ПО оказывают на частную жизнь.
Исходя из этого возникает еще ряд требований к инженерному программированию. Они состоят в необходимости разработки и сопровождения ПО, которое гарантирует, что ВС являются:
- исключительно надежными
- удобными в использовании
- естественными
- проверяемыми
- труднодоступными для злоупотреблений
- оставляющими главную роль за человеком, а не за машиной.
Попытка сформулировать общую цель инженерного программирования, достижение которой привело бы к удовлетворению всех указанных требований, обречена на неудачу, так как некоторые требования противоречат
друг другу.
Пример противоречий: пяти бригадам программистов дано одно и то же задание по программированию. Однако перед разными бригадами были поставлены разные цели.
Табл.2.2.Оценки результатов работы бригад
----------------------T----------------------------------------------¬
¦Цель бригады - ¦ Оценки (1-наилучшая, 5-наихудшая) ¦
¦ +--------T-----------T-------T--------T--------+
¦оптимизировать ¦затраты ¦число опе- ¦объем ¦ясность ¦четкость¦
¦ ¦труда ¦операторов ¦памяти ¦програм.¦данных ¦
+---------------------+--------+-----------+-------+--------+--------+
¦Затраты труда ¦ 1 ¦ 4 ¦ 4 ¦ 5 ¦ 3 ¦
¦ ¦ ¦ ¦ ¦ ¦ ¦
+---------------------+--------+-----------+-------+--------+--------+
¦Число операторов ¦ 2 ¦ 1 ¦ 2 ¦ 3 ¦ 5 ¦
¦программы ¦ ¦ ¦ ¦ ¦ ¦
+---------------------+--------+-----------+-------+--------+--------+
¦Объем требуемой ¦ 5 ¦ 2 ¦ 1 ¦ 4 ¦ 4 ¦
¦памяти ¦ ¦ ¦ ¦ ¦ ¦
+---------------------+--------+-----------+-------+--------+--------+
¦Ясность программы ¦ 4 ¦ 3 ¦ 3 ¦ 2 ¦ 2 ¦
¦ ¦ ¦ ¦ ¦ ¦ ¦
+---------------------+--------+-----------+-------+--------+--------+
¦Четкость выходных ¦ 3 ¦ 5 ¦ 5 ¦ 1 ¦ 1 ¦
¦данных ¦ ¦ ¦ ¦ ¦ ¦
L---------------------+--------+-----------+-------+--------+---------
Как видно, область инженерного программирования к счастью (или к несчастью) не столь проста.
Существует большое количество предлагаемых в качестве рекомендаций "стандартов" программирования: "разрабатывайте сверху-вниз", "доказывайте правильность программ", "разрабатывайте дважды", "используйте метод главного программиста", "программируйте структурно", "четко определяйте этапы", "привлекайте к работе пользователя" и т.д. Каждый из этих советов способствует выполнению определенных требований, но никак не учитывает другие и фактически препятствует их удовлетворению.
Наиболее важным в инженерном программировании является знание методов достижения разнообразных, возможно, противоречащих друг другу целей и согласования разнообразных применяемых средств, каждое из которых в зависимости от ситуации в различной степени помогает или мешает достижению конкретной цели.
Эффективность инженерного программирования основывается на осуществлении двух основных подцелей:
- получение качественного программного изделия
- реализация эффективного процесса разработки и сопровождения ПО.
Каждая из этих подцелей состоит из следующих трех компонентов:
- учет человеческих факторов
- управление ресурсами
- программотехника (технология программирования).
В общем случае цели инженерного программирования можно предста вить следующей иерархической структурой (рис.2.2).
----------------------------------------------¬
¦ Эффективность инженерного программирования ¦
L-------T-------------------------------T----- ¦ ¦
--------------------+--------¬ ------------+----------------¬
¦ Качество программного ¦ ¦ Эффективность процесса ¦
¦ изделия ¦ ¦ разработки ПО ¦
L---T-----------T-----------T- LT-----------T----------T---- ¦ ¦ ¦ ¦ ¦ ¦
----+----¬ ----+----¬ ----+----¬ -----+---¬ -----+---¬ ----+----¬
¦Человеч.¦ ¦Управлен¦ ¦Програм-¦ ¦Человеч.¦ ¦Управлен¦ ¦Програм-¦
¦факторы ¦ ¦ресурсам¦ ¦мотехник¦ ¦факторы ¦ ¦ресурсам¦ ¦мотехник¦
L--------- L--------- L--------- L--------- L--------- L-------- Легкость Эффектив- Специфици- Планируе- Анализиру- Осуществи использова ность рованность: мость емость эф- мость
ния Сбаланси- полнота Организу- фективности Подтверж Удовлетво- рованность непротиво- емость затрат даемость
рение пот- Измеряе- речивость Укомплек- Планируе- Полнота и
ребностей мость безопас- тованность мость непротив опользовате- ность штатов Оценивае- речивость
ля осуществи- Руководи- мость требований
Реализация мость мость Контроли- Подтвержда потенц.спо- проверяе- Контроли- руемость емость
собностей мость руемость Выполняе- Проектируе пользовате- Правиль- Автомати- мость мость изделя лей ность зируемость сроков и лия
Следование Адаптиру- Следование бюджета Программи модифицир. емость: модифицир. руемость
"золотому" структури- "золотому" Комплекси правилу рованность правилу руемость
независи- Внедряе мость мость
понятность Сопровож даемость
Снимаемость
Управляе мость кон фигурацией
Рис.2.2.Структура целей инженерного программирования.
2.2. Типы пользователей
2.2.1. Уровни пользователей ПО
Можно выделить три квалификационные категории пользователей, которые занимаются разработкой и использованием программного обеспечения. К первому уровню относятся разработчики ПО - специалисты в области применения ЭВМ, способные разрабатывать базовые методы, средства и оснащение ПО, общесистемное ПО, инструментальные и технологические средства, осуществлять генерацию и настройку ПО на условия конкретного применения.я.
Ко второму - те, кто хорошо знает тонкости построения системы и может ее модифицировать, то есть прикладные программисты, которые знают методологию проектирования, алгоритмы прикладной области и могут разрабатывать специализированное ПО, используя общесистемное ПО.
К третьему относятся пользователи, работающие в системе с помощью ориентированного на них языка взаимодействия. Процесс работы в этом случае сводится к заданию исходных данных, постановке задачи, проведению расчетов, анализу результатов и принятию решений.
2.2.2. Психофизиологические особенности взаимодействия человека и ЭВМ
ЭВМ дополняет человека, но не заменяет его, поэтому рассмотрение основных особенностей их сотрудничества является необходимым.м.
Логический метод рассуждения. У человека он основан на интуиции, на использовании накопленного опыта и воображения. Метод ЭВМ строгий и систематический. Наиболее удачным является сочетание когда ЭВМ реализует отдельные расчетные процедуры, а их логическая последовательность определяется человеком - создателем проектируемого объекта.
Способность к обучению. Человек обучается постепенно, степень "образованности" ЭВМ определяется ее программным обеспечением. Желательно, чтобы количество информации, получаемой на запрос пользователя, было переменным и могло изменяться по требованию пользователя.
Обращение с информацией. Емкость мозга человека для сохранения детализированной информации невелика, но обладает интуитивной, неформальной возможностью ее организации. Эффективность вторичного обращения к памяти зависит от времени. В ЭВМ емкость памяти большая, организация формальная и детализированная, вторичное обращение не зависит от времени. Поэтому целесообразно накапливать и организовывать информацию автоматическим путем и осуществлять ее быстрый вызов по удобным для человека признакам.
Оценка информации. Человек умеет хорошо разделять значимую и несущественную информацию. ЭВМ таким свойством не обладает. Поэтому должна существовать возможность макропросмотра информации большого объема, что позволяет человеку выбрать интересующую его часть, не изучая всю накопленную информацию.
Отношение к ошибкам. Человек часто допускает существенные ошибки, исправляя их интуитивно, при этом метод обнаружения ошибок чаще всего также интуитивный. ЭВМ, наоборот, не проявляет никакой терпимости к ошибкам и метод обнаружения ошибок строго систематичен. Однако в области формальных ошибок возможности ЭВМ значительно больше, чем при обнаружении неформальных. Поэтому нужно обеспечить возможность пользователю вводить в ЭВМ исходную информацию в свободной форме, написанную по правилам, близким к обычным математическим выражениям и к разговорной речи. ЭВМ выполняет контроль и преобразование информации к стандартному виду, удобному в процедурах обработки и формального устранения ошибок. Затем желательно обратное преобразование этой информации для показа пользователю в наглядной, например, графической форме, для обнаружения смысловых ошибок.
Обращение со сложными описаниями. Человеку трудно воспринять большое количество информации. Поэтому следует поручать ЭВМ автоматическое разбиение сложных конфигураций на относительно независимые части, охватываемые одним взглядом. Естественно, что изменения, сделанные в одной из этих частей, должны автоматически производиться во всех остальных.
Распределене внимания на несколько задач. Выполнить это условие человеку, в основном, не удается. При решении подзадачи приходится отвлекаться от основной задачи. Поэтому в ЭВМ организована система прерываний, восстанавливающая состояние основной задачи к моменту, нужному для пользователя. Аналогичным образом ЭВМ обслуживает процедуру анализа нескольких вариантов решения.
Память по отношению к проведенной работе. Человек может забыть как то, что уже сделано, так и то, что ему запланировано еще сделать. Этот недостаток компенсируется ЭВМ, которая четко фиксирует и информирует пользователя о выполненных процедурах и предстоящей работе.
Способность к сосредоточиванию. Эта способность у человека зависит от многих факторов, например, продолжительности и напряжения внимания, влияния среды, общего состояния. Усталостью обуславливается рассеянность, удлинение реакций, нецелесообразные действия. В связи с этим интерактивная система с разделением времени должна адаптироваться к времени реакции отдельного пользователя.
Терпение. При многократном повторении одних и тех же действий человек может испытывать чувство досады. Поэтому предусматривается, например, ввод исходных данных одним массивом при многократном анализе этих данных. К этому же относится включение в системы макрокоманд или гибкие сценарии.
Самочувствие. ЭВМ должна беречь самочувствие пользователя, его чувство собственного достоинства и показывать ему, что именно машина его обслуживает, а не наоборот. Вопросы, ответы и замечания должны соответствовать разговору между подчиненным и его руководителем, определяющим ход и направление процесса проектирования.
Эмоциональность. Это чувство свойственно человеку и чуждо ЭВМ. ПО должно возбуждать у пользователя положительные эмоции и не допускать отрицательных.
2.3. Классификация ПО и количественные характеристики
В основу первой классификации может быть положен объем ПО, выражаемый числом исходных команд (ЧИК). Этот термин - исходные команды, охватывает все команды, разработанные в ходе проектирования и переработанные в машинный код с помощью препроцессоров, компиляторов и ассемблеров. Исходные команды не включают комментарии и штатное ПО, но включают операторы языка управления заданиями, операторы ы флрмата и описание.
Исходя из числа исходных команд (ЧИК) можно классифицировать ПО следующим образом по размеру:
Малый........... 2 000 ЧИК
Промежуточный... 8 000 ЧИК Средний......... 32 000 ЧИК
Большой.........128 000 ЧИК
Введем следующие обозначения. Будем считать, что человеко-месяц (ЧМ) состоит из 152 часов рабочего времени. Тогда для преобразования можно использовать следующие правила:
для получения человеко-часов....умножить ЧМ на 152
для получения человеко-дней.....умножить ЧМ на 19
для получения человеко-годов....разделить ЧМ на 12
Если возможна предварительная оценка разрабатываемого ПО в тыся чах исходных команд (КЧИК), то затраты труда в ЧМ и сроки разработки могут быть определены уравнениями
1,05 0,38
ЧМ=2,4*(КЧИК) СР=2,5*(ЧМ)
Эти же данные можно представить следующей таблицей.
Табл.2.3.Характеристики проектов распространенного типа
-------------------T-----------T---------------T----------T----------¬
¦Размер ПО, КЧИК ¦ Затраты ¦ Производитель-¦ Сроки, ¦ Средние ¦
¦ ¦ труда, ЧМ ¦ ность, ЧИК/ЧМ ¦ месяцы ¦ штаты, ЧИ¦
+------------------+-----------+---------------+----------+----------+
¦Малый, 2 ¦ 5,0 ¦ 400 ¦ 4,6 ¦ 1,1 ¦
+------------------+-----------+---------------+----------+----------+
¦Промежуточный, 8 ¦ 21,3 ¦ 376 ¦ 8,0 ¦ 2,7 ¦
+------------------+-----------+---------------+----------+----------+
¦Средний, 32 ¦ 91,0 ¦ 352 ¦ 14,0 ¦ 6,5 ¦
+------------------+-----------+---------------+----------+----------+
¦Большой, 128 ¦ 392,0 ¦ 327 ¦ 24,0 ¦ 16,0 ¦
L------------------+-----------+---------------+----------+-----------
Приведенные в табл.2.3 данные относятся к коммерческим программным продуктам, подразумевающим тщательное документирование, отладку, обеспечение надежности при наличии ошибок, обучение пользователей и т.п. Необходимо помнить, что затраты на такую разработку примерно в три раза выше, чем на персональную программу.
Данные табл.2.3 получены на основании анализа 63 проектов разработки ПО для разных типов ЭВМ, разных объемов, разного назначения, использующего различные языки программирования.
Второй характеристикой для классификации ПО может служить качественная оценка. Различают три типа ПО: распространенный, полунезависимый и встроенный.
Распространенный тип характеризуется тем, что ПО разрабатывается относительно небольшой группой специалистов в условиях своей организации. Большинство связанных с проектом людей обладают большим опытом работы с аналогичными системами в условиях своей организации.
Это означает, что большинство участников проекта могут с пользой участвовать на начальных стадиях разработки, не создавая больших накладных расходов на обмен информацией о сущности проекта.
В проекте распространенного типа налагаются относительно менее жесткие ограничения на соответствие ПО требованиям и спецификациям интерфейса.
Другими характерными чертами ПО распространенного типа являются следующие:
- стабильные условия разработки проекта;
- минимальная необходимость новых системных и алгоритмических решений;
- относительно малое поощрение за раннее завершение проекта;
- относительно малый размер (как правило, до 50 КЧИК).
Встроенный тип отличается от других жесткими ограничениями на характеристики ЭВМ и правила использования интерфейса. Такое изделие должно работать при тесной взаимосвязи аппаратуры, программ, руководств и вычислительных процессов. (Пример - система резервирования авиабилетов или система управления воздушным движением).
При разработке встроенного ПО, как правило, отсутствует возможность договориться об уменьшении изменений и исправлений в программах при модификации требований и интерфейса. Поэтому большие затраты труда на установление соответствия ПО своим спецификациям и обеспечение правильности изменений.
По сравнению с распространенным встроенный проект, как правило, планируется при меньшем объеме информации об условиях его реализации.
Это требует привлечения бригады аналитиков на ранних стадиях проекта для избежания огромных накладных расходов.
После завершения проектирования изделия лучшей стратегией осуществления встроенного проекта является привлечение очень большой группы программистов для параллельного выполнения детального проектирования, кодирования и автономной отладки.
Полунезависимый тип ПО занимает промежуточное положение между распространенными и встроенными типами. Промежуточность положения определяется наличием любого из следующих свойств:
- промежуточные значения характеристик проекта;
- смещение характеристик распространенного и встроенного типов.
Обычно не превосходит 300 КЧИК.
Теперь можно расширить табл.2.3 характеристиками для двух других типов (табл.2.4).
Табл.2.4.Оценки для разработки ПО разных типов
--------T--------T----------------------------------------------------¬
¦Харак- ¦Тип раз-¦ Оценки для размеров ¦
¦терис- ¦работки +-------T----------T---------T---------T-------------+
¦тики ¦ ¦ малый,¦ промежу- ¦ средний ¦ большой ¦очень большой¦
¦ ¦ ¦ 2 КЧИК¦ точный, ¦ 32 КЧИК ¦ 128 КЧИК¦512 КЧИК ¦
¦ ¦ ¦ ¦ 8 КЧИК ¦ ¦ ¦ ¦
+-------+--------+-------+----------+---------+---------+-------------+
¦Затраты¦Распр. ¦ 5,0 ¦ 21,3 ¦ 91 ¦ 397 ¦ ¦
¦труда, ¦Полун. ¦ 6,5 ¦ 31,0 ¦ 146 ¦ 687 ¦ 3250 ¦
¦ЧМ ¦Встр. ¦ 8,3 ¦ 44,0 ¦ 230 ¦ 1216 ¦ 6420 ¦
+-------+--------+-------+----------+---------+---------+-------------+
¦Произво¦Распр. ¦ 400 ¦ 376 ¦ 352 ¦ 327 ¦ ¦
¦дитель-¦Полун. ¦ 308 ¦ 258 ¦ 219 ¦ 186 ¦ 158 ¦
¦ность, ¦Встр. ¦ 241 ¦ 182 ¦ 139 ¦ 105 ¦ 80 ¦
¦ЧИК/ЧМ ¦ ¦ ¦ ¦ ¦ ¦ ¦
+-------+--------+-------+----------+---------+---------+-------------+
¦Сроки ¦Распр. ¦ 4,6 ¦ 8,0 ¦ 14 ¦ 24 ¦ ¦
¦разра- ¦Полун. ¦ 4,8 ¦ 8,3 ¦ 14 ¦ 24 ¦ 42 ¦
¦ботки, ¦Встр. ¦ 4,9 ¦ 8,4 ¦ 14 ¦ 24 ¦ 42 ¦
¦месяцы ¦ ¦ ¦ ¦ ¦ ¦ ¦
+-------+--------+-------+----------+---------+---------+-------------+
¦Среднее¦Распр. ¦ 1,1 ¦ 2,7 ¦ 6,5 ¦ 16 ¦ ¦
¦число ¦Полун. ¦ 1,4 ¦ 3,7 ¦ 10,0 ¦ 29 ¦ 77 ¦
¦исполни¦Встр. ¦ 1,7 ¦ 4,2 ¦ 16,0 ¦ 51 ¦ 157 ¦
¦телей ¦ ¦ ¦ ¦ ¦ ¦ ¦
L-------+--------+-------+----------+---------+---------+------------- 1.05
4M = 2.4*КЧИК - распространенный
1.12
4М = 3.0*КЧИК - полунезависимый
4М = 3.6*КЧИК - встроенный
2.4. Жизненный цикл программного обеспечения
Рассмотрим жизненный цикл программного обеспечения, то есть процесс его создания и применения от начала до конца. Этот процесс состоит из нескольких стадий: определения требований и спецификаций, проектирования, программирования, отладки и сопровождения.я.
Первая стадия - определение требований и спецификаций, может быть названа стадией системного анализа. Общие требования к ПО - надежность, технологичность, правильность, универсальность, эффективность, информационная согласованность и т.д. Они дополняются требованиями заказчика, включающими пространственно-временные ограничения, необходимые функции и возможности, режимы функционирования, требования точности и надежности и т.д., то есть вырабатывается описание системы с точки зрения пользователя. При определении спецификаций производится точное описание функций ПО, разрабатываются и утверждаются входные и промежуточные языки, форма выходной информации для каждой из подсистем, описывается возможное взаимодействие с другими программными комплексами, специфицируются средства расширения и модификации ПО, разрабатываются интерфейсы обслуживающих и основных подсистем, решаются вопросы базы данных, утверждаются основные алгоритмы. Итогом выполнения этого этапа являются эксплуатационные и функциональные спецификации, содержащие конкретное описание ПО. Разработка спецификаций требует тщательной работы системных аналитиков, постоянно контактирующих с заказчиками, которые в большинстве случаев не способны сформулировать четкие и реальные требования.
Эксплуатационные спецификации содержат сведения о быстродействии ПО, затратах памяти, требуемых технических средствах, надежности и т.д.
Функциональные спецификации определяют функции, которые должно выполнять ПО, то есть в них определяется что надо делать, а не как это делать.
Спецификации должны быть полными, точными и ясными. Полнота исключает необходимость получения разработчиками ПО в процессе их работы от заказчиков иных сведений, кроме содержащихся в спецификациях. Точ ность не позволяет различных толкований. Ясность подразумевает легкость понимания как заказчиком, так и разработчиком при однозначном толковании.
Значение спецификаций:
1.спецификации являются заданием на разработку ПО и их выполнение закон для разработкчика;
2.спецификации используются для проверки готовности ПО;
3.спецификации являются неотемлимой частью программной документации, облегчают сопровождение и модификацию ПО.
Второй стадией является проектирование ПО. На этом этапе:
1.формируется структура ПО и разрабатываются алгоритмы, задаваемые спецификациями;
2.устанавливается состав модулей с разделением их на иерархические уровни на основе изучения схем алгоритмов;
3.выбирается структура информационных массивов, составляющих базу данных;
4.фиксируются межмодульные интерфейсы.
Цель этапа - иерархическое разбиение сложных задач создания ПО на подзадачи меньшей сложности. Результатом работы на этом этапе являются спецификации на отдельные модули, дальнейшая декомпозиция которых нецелесообразна.
Третья стадия - программирование. На данном этапе производится программирование модулей. Этап менее сложен по сравнению со всеми остальными. Проектные решения, полученные на предыдущей стадии, реализуются в виде программ. Разрабатываются отдельные блоки и подключаются к создаваемой системе. Одна из задач - обоснованный выбор языков программирования. На этой же стадии решаются все вопросы, связанные с особенностями типа ЭВМ.
Четвертая стадия - отладка ПО, заключающаяся в аппробировании всех требований, всех структурных элементов системы и такого количества всевозможных комбинаций, какое только позволяет здравый смысл и бюджет. Этап предполагает выявление в программах ошибок, проверку работоспособности ПО, а также его соответствие спецификациям.
Пятая стадия - сопровождение, то есть процесс исправления ошибок, координации всех элементов системы в соответствии с потребностями пользователя, внесения всех нужных ему исправлений и изменений. Это вызвано, как минимум, двумя причинами: во-первых, в ПО остаются ошибки, не выявленные при тестировании; во-вторых, пользователи в ходе эксплуатации ПО настаивают на внесении в него изменений и его дальнейшем совершенствовании.
В общем случае, в процессе разработки ПО требуется осуществить несколько итераций.
Распределение временных и стоимостных затрат по отдельным стадиям жизненного цикла программного обеспечения представлено в табл.2.5 и 2.6.
Табл.2.5.Затраты по стадиям жизненного цикла ПО
-------------------------------------------¬
¦ Сведения из разных источников ¦
-------------------+--------T---------T-------T--------T------+-------¬
¦Стадии жизненного ¦Гласс Р.¦Энкарнач-¦Боэм Б.¦Федорчук¦Вишня-¦ ¦
¦цикла программного¦Нуазо Р.¦чо Ж. ¦ ¦Чернень-¦ков ¦Среднее¦
¦обеспечения ¦ ¦ ¦ ¦кий ¦ ¦ ¦
+------------------+--------+---------+-------+--------+------+-------+
¦Определение требо-¦ 10 ¦ 15 ¦ 6 ¦ 6 ¦ 6 ¦ 8,6 ¦
¦ваний и специфик. ¦ ¦ ¦ ¦ ¦ ¦ ¦
+------------------+--------+---------+-------+--------+------+-------+
¦Проектирование ¦ 10 ¦ 12 ¦ 18 ¦ 5 ¦ 6 ¦ 10,2 ¦
+------------------+--------+---------+-------+--------+------+-------+
¦Программирование ¦ 10 ¦ 12 ¦ 9 ¦ 7 ¦ 6 ¦ 8,8 ¦
+------------------+--------+---------+-------+--------+------+-------+
¦Отладка ¦ 20 ¦ 15 ¦ 17 ¦ 15 ¦ 14 ¦ 16,2 ¦
+------------------+--------+---------+-------+--------+------+-------+
¦Сопровождение ¦ 50 ¦ 46 ¦ 50 ¦ 67 ¦ 68 ¦ 56,2 ¦
¦------------------+--------+---------+-------+--------+------+-------+
¦Всего ¦ 100 ¦ 100 ¦ 100 ¦ 100 ¦ 100 ¦ 100 ¦
L------------------+--------+---------+-------+--------+------+--------
Табл.2.6.Основные параметры стадий жизненного цикла ПО
---------------------T--------------T-------------T--------------¬
¦Стадии жизненного ¦ Количество ¦ Обнаруже- ¦ Затраты на ¦
¦цикла программного ¦ ошибок,%% ¦ ние ошибок ¦ устранение ¦
¦обеспечения ¦ ¦ %% ¦ ошибок,%% ¦
+--------------------+--------------+-------------+--------------+
¦Определение требо- ¦ ¦ ¦ 9 ¦
¦ваний и спецификаций¦ ¦ ¦ ¦
+--------------------+--------------+-------------+--------------+
¦Проектирование ¦ 61-64 ¦ ¦ 6 ¦
+--------------------+--------------+-------------+--------------+
¦Программирование ¦ 36-39 ¦ ¦ 10 ¦
+--------------------+--------------+-------------+--------------+
¦Отладка ¦ ¦ 46 ¦ 12 ¦
+--------------------+--------------+-------------+--------------+
¦Сопровождение ¦ ¦ 54 ¦ 63 ¦
L--------------------+--------------+-------------+---------------
Основные временные соотношения между отдельными видами работ можно представить сетевым графиком разработки ПО.
---¬ ---¬ ---¬
¦13¦ ¦13¦ ¦ 8¦
----------+--+ ----------+--+ ----------+--+
¦ Разработка ¦----->¦ Проектиро- ¦----->¦ Документи- ¦------¬
¦ требований ¦ ¦ вание ¦ ¦ рование ¦ ¦
L------------- L------------- L------------- ¦ v ¦ ¦ ¦
¦ ¦ ---¬ ¦ ¦
¦ v ¦ 8¦ ¦ ---¬ ¦
¦ ----------+--+ v ¦ 8¦ v
---------¬ ¦ Подготовка ¦ ----------------+--+ --------¬
¦ Начало ¦ ¦ данных для ¦ ¦ Программирование ¦ ¦ Конец ¦
L--------- ¦ отладки ¦ L------------------- L------- ¦ L------------- ¦ v
¦ ¦ ¦ ¦ ¦
¦ ¦ L-------------------¬ ¦ ¦
¦ ¦ ¦ ¦ ¦
v v v v ¦
-------------¬ -------------¬ -------------¬ ¦
¦ Планирова- ¦ ¦ Разработка ¦ ¦ Испытание ¦ ¦
¦ ние отладки¦----->¦ драйверов ¦----->¦ программно-¦------ ¦ ¦ ¦ тестов ¦ ¦ го изделия ¦
L---------T--+ L---------T--+ L---------T--+ ¦ 8¦ ¦25¦ ¦17¦
L--- L--- L---
Рис.2.7.Сетевой график разработки ПО.
(цифры означают время в %% от полного времени первых четырех этапов жизненного цикла)
2.5. Общие принципы разработки ПО
2.5.1. Общие принципы
Программное обеспечение различается по назначению, выполняемымфункциям, формам реализации. В этом смысле ПО - сложная, достаточно уникальная программная система. Однако можно полагать, что существуют некоторые общие принципы, которые следует использовать при разработке ПО.
Частотный принцип. Основан на выделении в алгоритмах и в обрабатываемых структурах действий и данных по частоте использования. Для действий, которые часто встречаются при работе ПО, обеспечиваются условия их быстрого выполнения. К данным, к которым происходит частое обращение, обеспечивается наиболее быстрый доступ.
"Частые" операции стараются делать более короткими.
Принцип модульности. Под модулем в общем случае понимают функциональный элемент рассматриваемой системы, имеющий оформление, законченное и выполненное в пределах требований системы, и средства сопряжения с подобными элементами или элементами более высокого уровня данной или другой системы.
Способы обособления составных частей ПО в отдельные модули могут быть существенно различными. Чаще всего разделение происходит по функциональному признаку. В значительной степени разделение системы на модули определяется используемым методом проектирования ПО.
Принцип функциональной избирательности. Этот принцип является логическим продолжением частотного и модульного принципов и используется при проектировании ПО, объем которого существенно превосходит имеющийся объем оперативной памяти. В ПО выделяется некоторая часть важных модулей, которые постоянно должны быть в состоянии готовности для эффективной организации вычислительного процесса. Эту часть в ПО называют ядром или монитором. При формировании состава монитора требуется удовлетворить двум противоречивым требованиям. В состав монитора, помимо чисто управляющих модулей, должны войти наиболее часто используемые модули. Количество модулей должно быть таким, чтобы объем памяти, занимаемой монитором, был не слишком большим. Программы, входящие в состав монитора, постоянно хранятся в оперативной памяти. Остальные части ПО постоянно хранятся во внешних запоминающих устройствах и загружаются в оперативную память только при необходимости, перекрывая друг друга при необходимости.
Принцип генерируемости. Основное положение этого принципа определяет такой способ исходного представления ПО, который бы позволял осуществлять настройку на конкретную конфигурацию технических средств, круг решаемых проблем, условия работы пользователя.
Принцип функциональной избыточности. Этот принцип учитывает возможность проведения одной и той же работы различными средствами. Особенно важен учет этого принципа при разработке пользовательского интерфейса для выдачи данных из-за психологических различий в восприятии информации.
Принцип "поумалчиванию". Применяется для облегчения организации связей с системой как на стадии генерации, так и при работе с уже готововым ПО. Принцип основан на хранении в системе некоторых базовых описаний структур, модулей, конфигураций оборудования и данных, определяющих условия работы с ПО.
Эту информацию ПО использует в качестве заданной, если пользователь забудет или сознательно не конкретизирует ее. В данном случае ПО само установит соответствующие значения.
2.5.2. Общесистемные принципы
При создании и развитии ПO рекомендуется применять следующие общесистемные принципы:
- принцип включения, который предусматривает, что требования к созданию, функционированию и развитию ПО определяются со стороны более сложной, включающей его в себя системы;
- принцип системного единства, который состоит в том, что на всех стадиях создания, функционирования и развития ПО его целостность будет обеспечиваться связями между подсистемами, а также функционированием подсистемы управления;
- принцип развития, который предусматривает в ПО возможность его наращивания и совершенствования компонентов и связей между ними;
- принцип комплексности, который заключается в том, что ПО обеспечивает связность обработки информации как отдельных элементов, так и для всего объема данных в целом на всех стадиях обработки;
- принцип информационного единства, то есть во всех подсистемах, средствах обеспечения и компонентах ПО используются единые термины, символы, условные обозначения и способы представления;
- принцип совместимости, который состоит в том, что язык, символы, коды и средства обеспечения ПО согласованы, обеспечивают совместное функционирование всех его подсистем и сохраняют открытой структуру системы в целом;
- принцип инвариантности, который предопределяет, что подсистемы и компоненты ПО инвариантны к обрабатываемой информации, то есть являются универсальными или типовыми.
