Пример готовой курсовой работы по предмету: Информационные технологии
Содержание
Введение……………………………………………………………………………3
1. Теоретические основы оценки размера ПО
1.1 Основные понятия в области сложности программ…………………………6
1.2 Анализ методов оценки размера программ………………………………… 9
1.3 Анализ существующих программных средств оценки программ………..13
2. Обзор методов по оценке размера программного обеспечения
2.1 Метрики размера программ
2.1.1 Простейшие объемные метрики…………………………………………..17
2.1.2 Метрики Холстеда………………………………………………………… 17
2.2 Метрики сложности потока управления программ
2.2.1 Метрика Маккейба…………………………………………………………19
2.2.2 Метрика Майерса………………………………………………………….21
2.2.3 Метрика Джилба…………………………………………………………..21
2.3 Метрики сложности и размера потока данных…………………………… 21
2.3.1 Метрика обращения к глобальным переменным……………………….22
2.3.2 Спен…………………………………………………………………………22
2.3.3 Метрика Чепина…………………………………………………………… 23
2.4 Комплексные меры сложности и размера программ……………………..24
Заключение……………………………………………………………………… 29
Библиографический список…………………………………………………….30
Выдержка из текста
На современном этапе развития не вызывает сомнения необходимость развития теоретических основ оценивания качества и размера программных средств (ПС).
Во-первых, постоянное наращивание сложности ПС, как правило, ведет к увеличению числа исходных ошибок в тексте программы, что снижает ее качество. Во-вторых, возрастает вероятность увеличения уязвимостей в ПС, которыми может воспользоваться злоумышленник. Кроме того многообразие ПС, имеющих сходное функциональное назначение, создает жесткую конкуренцию на рынке программной продукции. Число ПС одного класса достигает сотен, а если учесть еще наличие различных версий одного и того же ПС, то и тысяч единиц. Возникает вопрос, как выбрать необходимое ПС, которое будет оптимально простым и надёжным. На первый взгляд может показаться, что старые версии ПС следует безоговорочно «сбрасывать со счетов». Однако, как показывает практика, зачастую новые версии ПС – «сырые» и уступают по качеству предыдущим. К тому же, как правило, требования последних версий ПС к аппаратным средствам жестче, что при выборе ПС для работы на компьютере, заданной комплектации, является одним из важнейших критериев выбора.
В оценивании размера ПС заинтересованы как его разработчики, так и потребители. Для разработчиков оценивание важно уже на этапе проектирования ПС для прогнозирования коммерческого успеха продукта с планируемыми значениями характеристик у пользователей. Оценивание размера ПС на этапе его отладки позволяет разработчику принять решение о завершении этого этапа. Для пользователей же важна уверенность в том, что их информация будет надёжно защищена в процессе эксплуатации ПС. Из выше сказанного следует, что одним из параметров влияющих на защищённость информации, является размер и качество ПС.
Сами цифровые компьютеры сложнее, чем большинство изготавливаемых людьми вещей. Число их состояний очень велико, поэтому их трудно понимать, описывать и тестировать. У программных систем число возможных состояний на порядки величин превышает число состояний компьютеров.
Аналогично, масштабирование программного объекта – это не просто увеличение в размере тех же самых элементов, это обязательно увеличение числа различных элементов. В большинстве случаев эти элементы взаимодействуют между собой неким нелинейным образом, и сложность целого растет значительно быстрее, чем линейно.
Сложность программ является существенным, а не второстепенным свойством. Поэтому описания программных объектов, абстрагирующиеся от их сложности, часто абстрагируются от их сущности. Математика и физические науки за три столетия достигли больших успехов, создавая упрощенные модели сложных физических явлений, получая из этих моделей свойства и проверяя их опытным путем. Это удавалось благодаря тому, что сложности, игнорировавшиеся в моделях, не были существенными свойствами явлений. И это не действует, когда сложности являются сущностью.
Многие классические трудности разработки программного обеспечения проистекают из этой сложности сущности и ее нелинейного роста при увеличении размера. Сложность служит причиной трудности процесса общения между участниками бригады разработчиков, что ведет к ошибкам в продукте, превышению стоимости разработки, затягиванию выполнения графиков работ. Сложность служит причиной трудности перечисления, а тем более понимания, всех возможных состояний программы, а отсюда возникает ее ненадежность. Сложность функций служит причиной трудностей при их вызове, из-за чего программами трудно пользоваться.
Сложность структуры служит причиной трудностей при развитии программ и добавлении новых функций так, чтобы не возникали побочные эффекты. Сложность структуры служит источником невизуализуемых состояний, в которых нарушается система защиты.
Список использованной литературы
1. Гради Б. Объектно-ориентированный анализ и проектирование с примерами приложений на С++.
2. Червяков Р.С. Статистическое исследование системы метрик сложности и размера программного обеспечения. Автореферат, 2003.
3. Elaine Fedchak and Robert Vienneau. A History of Software Measurement at Rome Laboratory. – http://www.dacs.dtic.mil/techs/history/His.RL.2.1.4.html
4. Изосимов А.В., Рыжко А.Л. Метрическая оценка разхмера программ. − М: Издательство МАИ, 1989.
5. Черноножкин С.К. Методы и инструменты метрической поддержки разработки качественных программ. Автореферат, 1998.
6. Фленов М. Библия Delphi. – СПб.: БХВ-Петербург, 2004.
7. Борбот А.Ю., Зацепин Е.Н., Навоша А.И.. Оценка искусственного освещения в производственных помещениях: Метод. пособие для практических занятий по дисциплине «Охрана труда и основы экологии» для студентов всех специальностей и форм обучения БГУИР. − Мн.: БГУИР, 2002. – 16 с.
8. Уилсон Р. Человек за компьютером. // Мир ПК, № 1 − 1991.
9. Сибаров К.Г., Сколотнев Н.Н., Васин В.К., Начинаев В.Н. Охрана труда в вычислительных центрах: учебное пособие. − М.: Машиностроение, 1985.
