Программа или логически связанная совокупность программ на носителях данных, снабженная программной документацией, называется программным средством (ПС). Программа позволяет осуществлять некоторую автоматическую обработку данных на компьютере. Программная документация позволяет понять, какие функции выполняет та или иная программа ПС, как подготовить исходные данные и запустить требуемую программу в процесс ее выполнения, а также: что означают получаемые результаты. Кроме того, программная документация помогает разобраться в самой программе, что необходимо, например, при ее модификации.
Разработка ПО — это, прежде всего, нахождение способов получения качественного программного продукта. Качество ПО может измеряться во внешних (например, легкий в использовании, выполняется быстро) или во внутренних характеристиках (например, модульная конструкция, читабельный код).
Характеристики качества программного обеспечения:
— Корректность (правильность). Обеспечивает правильную обработку на правильных данных
Интровебинар «Школа 21» по направлению «Специалист по работе с данными, Data Scientist» Май 2023
— Устойчивость. «Элегантно» завершает обработку ошибок
— Расширяемость. Может легко адаптироваться к изменяющимся требованиям
— Многократность использования. Может использоваться и в других системах, а не только в той, для которой было создано.
— Совместимость. Может легко использоваться с другим программным обеспечением
— Эффективность. Эффективное использование времени, компьютерной памяти, дискового пространства и т.д.
— Переносимость. Можно легко перенести на другие аппаратные и программные средства
— Верификация. Простота проверки, легкость разработки тестов при обнаружении ошибок, легкость обнаружения мест, где программа потерпела неудачу, и т.д.
— Поддержка целостности. Защищает себя от неправильного обращения и неправильного употребления
— Легкость использования для пользователя и для будущих программистов
Корректность и устойчивость
Корректная программа работает, когда поданы на вход правильные данные. Она отвечает всем требованиям к спецификации данных и не терпит неудачу внутри заданного диапазона. Устойчивость подразумевает не только правильность. Устойчивая программа способна обработать ситуации, не запланированные проектом.
Эти ситуации включают некорректный ввод пользователя, аппаратный отказ и ошибки во время выполнения программы. Устойчивые системы терпят неудачу без потери критических данных.
Два основных принципа создания расширяемого программного обеспечения:
— Простота проекта. Более простые проект и архитектура позволяют произвести изменения намного быстрее и легче, чем при сложном проекте.
— Децентрализация. Разбиение сложных проблем на малые. Управляемость и независимость фрагментов, означающая, что они могут быть поделены внутри себя. Это значит, что изменения, могут быть выполнены без перекраивания других частей системы.
Многократность использования и совместимость
Многократное использование может просматриваться на различных уровнях: при анализе, проектировании и реализации. Оно поддерживает качество следующими способами:
НЕЙРОСЕТЬ своими руками за 10 минут на Python
— Если проекты и код могут повторно использоваться, то мы можем начинать с уже проверенных, опробованных и правильных компонент, качество которых уже является высоким.
— Время и энергия, сохраненные через многократное использование, могут применяться для улучшения других характеристик качества программы (например, корректности или устойчивости).
Совместимость программного обеспечения — мера того, насколько просто объединить различные программные изделия вместе для нового применения. Совместимое ПО поддерживает качество посредством использования прошлых усилий при формировании новых систем.
Понятность – легкость понимания документации, сопровождающей ПИ.
Каждое ПИ должно создаваться с учетом требований пользователя, определенных в техническом задании. Характеристики понятности:
Информативность – ПИ обладает информативностью, если оно содержит информацию, обеспечивающую понимание назначения ПИ, принятых ограничений, смыслового значения результатов работы отдельных компонентов ПИ.
Открытость – дает возможность понять назначение каждого оператора ПИ при чтении ее текста, т.е. каждый из идентификаторов должен нести смысловую нагрузку, например, SUM= CENA*KOL.
Согласованность ПИ – бывает внутренняя и внешняя.
Внутренняя согласованность должна обеспечивать единую терминологию, единую трактовку понятий и значений. Особое значение эта характеристика приобретает при создании программных комплексов, когда над проектом работает группа специалистов, и в процессе работы необходимы контакты по взаимоувязке программных модулей.
Внешняя согласованность обеспечивается однозначным соответствием создаваемого ПИ требованиям, изложенным в техническом проекте на его разработку.
Структурированность ПИ – делает его понятным для пользователя. Она предполагает создание ПИ в соответствии с определенными требованиями:
1 — Использование при программировании трех базовых конструкций:
а) линейная структура
б) условный переход
в) цикл (или последовательная).
2 — Подробное комментирование текста программ.
3 — Использование модульного программирования.
4 — Ограничение на объем модулей (количество операторов).
Надежность – свойство ПИ сохранять работоспособность в течение определенного периода времени в определенных условиях эксплуатации с учетом последствий для пользователя при любом отказе. Она характеризуется:
Завершенность – завершенное ПИ включает все необходимые для функционирования программные компоненты.
Точность — характеристика, определяющая точность результатов расчета в соответствии с их назначением. Например: если ведутся расчеты банковских операций, то разумная точность – 3 знака после запятой, с последующим округлением до 2 знаков. Если в программе производятся расчеты по биологическим экспериментам, на молекулярном уровне, то точность по 10-12 знаков после запятой.
Эффективность – выполнение требуемых функций при минимальных затратах ресурсов. Причем под ресурсами подразумевается: объем оперативной памяти, время работы процессора, объем внешней памяти, пропускная способность канала.
Модифицируемость – эта характеристика отражает возможность внесения изменений в ПИ без значительных затрат времени на последующую отладку. Эта характеристика включает в себя характеристику расширяемости ПИ, которая предполагает модификацию ПИ в части увеличения объема памяти либо числа функциональных модулей.
Оцениваемость – это существование критерия оценки ПИ и способа проверки соответствия этому критерию, по которым можно сравнить с другими подобными ПИ (критерии оценки в техническом проекте соответствует заданным требованиям: время работы модуля и т.д.).
Человеческий фактор (сервис):
Легкость использования ПИ.
ПИ должно удовлетворять требованиям пользователя.
ПИ должно реализовывать потенциальные потребности пользователя.
Мобильность – возможность работы ПИ в различных ОС
Качество программного обеспечения определяется в стандарте ISO 9126 как вся совокупность его характеристик, относящихся к возможности удовлетворять высказанные или подразумеваемые потребности всех заинтересованных лиц.
Отличие тестирования от контроля качества. Целью тестирования является нахождение максимального числа ошибок. Задача контроля качества является оценка результатов работы проектной группы (всех сотрудников и результатов их деятельности в процессе разработки ПО: программистов, тестировщиков, менеджеров проекта и т.д.).
Качеством можно управлять. Для этого разрабатывается план управления качеством, который включает в себя:
Определение метрик для измерения тех или иных аспектов процесса разработки программного продукта и самого разрабатываемого продукта.
Метрики нужны для численного измерения уровня качества. Как правило, в качестве метрик используются следующие характеристики:
Число строк кода
Время, за которое написано N строк кода
Степень дефектности (Число дефектов/Число строк кода) (под дефектами понимаются ошибки, найденные в результате тестирования)
Относительная оценка по 10-бальной шкале
План проведения инспектирования
План валидации и верификации
К контролю качества относится процедура аттестации ПО. Аттестация ПО проводится сторонними организациями, уполномоченными проверять ПО на соответствие определенным отраслевым стандартам.
Критерии качества программного обеспечения
1 Функциональные возможности
-способность к взаимодействию (с ОС и аппаратурой, м-ду др программами)
-защищенность (от предумышленных угроз, случайных дефектов программ)
-завершенность (наработка на отказ при отсутствии рестарта)
-устойчивость к дефектам (наработка при наличие рестарта)
— используемые ресурсы (процессорное время, память и т.д)
Источник: studfile.net
Определение критериев оценки качества программы. Характеристика средства и инструменты разработки программного обеспечения.
Разработка программного обеспечения — это, прежде всего, нахождение способов получения качественного программного продукта. Что мы подразумеваем, когда мы говорим о «качестве» программного обеспечения? Качество программного обеспечения может измеряться во внешних характеристиках или во внутренних характеристиках.
Внешние метрики — единственные, которые, в конце концов, действительно имеют значение. В таблице 1 приводится список наиболее общих внешних факторов, найденных в качественном программном обеспечении. Более подробно некоторые из них будут рассмотрены ниже.
Характеристики качества программного обеспечения
| Фактор | Означает |
| Корректность (правильность) | Обеспечивает правильную обработку на правильных данных |
| Устойчивость | «Элегантно» завершает обработку ошибок |
| Расширяемость | Может легко адаптироваться к изменяющимся требованиям |
| Многократность использования | Может использоваться и в других системах, а не только в той, для которой было создано. |
| Совместимость | Может легко использоваться с другим программным обеспечением |
| Эффективность | Эффективное использование времени, компьютерной памяти, дискового пространства и т.д. |
| Переносимость | Можно легко перенести на другие аппаратные и программные средства |
| Верификация | Простота проверки, легкость разработки тестов при обнаружении ошибок, легкость обнаружения мест, где программа потерпела неудачу, и т.д. |
| Поддержка целостности | Защищает себя от неправильного обращения и неправильного употребления |
| Легкость использования | Для пользователя и для будущих программистов |
Корректность и устойчивость
Легко спутать термины «Корректная программа» и «Устойчивая программа». Корректная программа работает, когда поданы на вход правильные данные. Она отвечает всем требованиям к спецификации данных и не терпит неудачу внутри заданного диапазона. Устойчивость подразумевает не только правильность. Устойчивая программа способна обработать ситуации, не запланированные проектом.
Эти ситуации включают некорректный ввод пользователя, аппаратный отказ и ошибки во время выполнения программы. Устойчивые системы терпят неудачу элегантно, без потери критических данных. Легко увидеть, что обе характеристики необходимы для любой системы, которая будет оценена как высококачественное программное обеспечение. Если система некорректна, то она бесполезна. Если система неустойчива, то она окажется неспособной справиться с задачей в реальной ситуации.
Требований меняются. Это — один из бесспорных фактов процесса разработки программного обеспечения. Высококачественная программа способна иметь дело с этими изменениями относительно безболезненно. Этот сорт адаптируемости — не является существенным для малых проектов, но становится определяющим, когда происходит «программирование в большом». Два основных принципа создания расширяемого программного обеспечения:
· Простота проекта. Более простые проект и архитектура позволяют произвести изменения намного быстрее и легче, чем при сложном проекте.
· Децентрализация. Разбиение сложных проблем на малые. Управляемость и независимость фрагментов, означающая, что они могут быть поделены внутри себя. Это значит, что изменения, могут быть выполнены без перекраивания других частей системы.
Эти принципы позволяют нам понять проблему в частях без опасения затеряться в несметном количестве непостижимых подробностей.
Многократность (повторность) использования и совместимость
Многократное использование может просматриваться на различных уровнях: при анализе, проектировании, и реализации. Оно поддерживает качество следующими способами:
· Если проекты и код могут повторно использоваться, то мы можем начинать с уже проверенных, опробованных и правильных компонент, качество которых уже является высоким.
· Время и энергия, сохраненные через многократное использование, могут применяться для улучшения других характеристик качества программы (например, корректности или устойчивости).
Совместимость программного обеспечения — мера того, насколько просто объединить различные программные изделия вместе для нового применения. Основы совместимости вытекают из общих проектных решений. Например, файловая система UNIX разработана таким образом, чтобы позволить малым инструментальным средствам хорошо работать вместе при решении сложных проблем. Противоположным примером является типичный беспорядок при совместной подготовке текстов и графических изображений. В этом случае, большие усилия должны быть затрачены на создание транслятора, которые позволяет одной программе работать с другой.
Совместимость и многократное использование идут «взявшись за руки», потому что повторно используемое программное обеспечение (например, plug
– некомплектная документация (т.е. нет документа целиком, либо раздела в документе).
Точность — характеристика, определяющая точность результатов расчета в соответствии с их назначением.
Например: если ведутся расчеты банковским операциям, то разумная точность – 3 знака после запятой, с последующим округлением до 2 знаков. Если в программе производятся расчеты по биологическим экспериментам, на молекулярном уровне, то точность по 10-12 знаков после запятой.
Эффективность – выполнение требуемых функций при минимальных затратах ресурсов. Причем под ресурсами подразумевается: объем оперативной памяти, время работы процессора, объем внешней памяти, пропускная способность канала.
Часто характеристика эффективности вступает в противоречие с другими характеристиками качественного ПИ.
Модифицируемость – эта характеристика отражает возможность внесения изменений в ПИ без значительных затрат времени на последующую отладку.
Эта характеристика включает в себя характеристику расширяемости ПИ, которая предполагает модификацию ПИ в части увеличения объема памяти либо числа функциональных модулей.
Оцениваемость – это существование критерия оценки ПИ и способа проверки соответствия этому критерию, по которым можно сравнить с другими подобными ПИ (критерии оценки в техническом проекте соответствует заданным требованиям: время работы модуля и т.д.).
1. Легкость использования ПИ.
2. ПИ должно удовлетворять требованиям пользователя.
3. ПИ должно реализовывать потенциальные потребности пользователя.
4. Необходимо при разработке ПИ следовать золотому правилу: относить к людям так же, как бы ты хотел, чтобы относились к тебе.
Мобильность – возможность работы ПИ в различных ОС.
Источник: megalektsii.ru
Тема: Информатика — нуждаюсь в информации и советах
04.07.2018, 16:23
=== 79 == предположительно важнейшее в математике ==
предположительно важнейшее в математике это
1.теория Множеств
2.логика
3.теория неравенств
4.теория совершенных и несовершенных пределов
=== 80 == информатика ==
информация — это форма материи
информатика — это наука о формах материи
важнейшим в информатике является
1.системотехника — наука о Системах
2.лингвистика — наука о интерфейсах Систем, уже описывалась в главе 53 — лингвистика человеческой речи
3.программирование — наука о формализации Систем
4.математика — наука о законах Систем
==
1.системотехника
Система может состоять из частей, имеющих следующие категории:
1.дерево — каталог объектов и других каталогов
2.ветвь — объект, базовый каталог характеристик
3.лист — характеристика объекта, базовая еденичная структура информации
все они адресуется своим личным идентификацационным именем
Система может иметь интерфейс связи с внешним миром, могущий быть представленным в самой Системе ветвями и листями
взаимодействуя друг с другом Системы могут образовывать МультиСистемы
автономная Система может иметь:
1.ядро — базовую её часть реализующую:
1.1 базовые функции
1.2 анализ информации
1.3 синтез информации
1.4 мировозрение анализа информации
1.5 мировозрение синтеза информации
2.инструментарий — набор функций
3.учебники — Базы Знаний методов применения функций
4.энциклопедии — Базы Знаний областей наук
5.область деятельности — область применения методов
6.область интерфейса ввода информации
7.область интерфейса вывода информации
8.область задач — поставленные Системе задачи
9.область хранения информации — может включать в себя несколько областей информации, иногда сразу все собранные в одном месте, например с интерфейсом в виде иерархического дерева каталогов и файлов
предупреждение: в написании этого труда похоже участвовало несколько авторов, когда писал я, Власкин Иван Иванович, дата рождения 1976-03-18, то я в начале абзацов писал текст без заглавных букв и в конце абзацев не ставил точки
Понятие алгоритма. Одним из фундаментальных понятий в информатике является понятие алгоритма. Происхождение самого термина связано с математикой. Это слово происходит от Algorithm — латинского написания имени Мухаммеда аль-Хорезми (787-850), выдающегося математика средневекового Востока. В XII в. был выполнен латинский перевод его математическог
=====
программирование включает разные категории программирования:
1.по типу логики решения задания (редукция, индукция, дедукция)
2.по направлению синтеза решения (программирование «сверху», программирование «снизу»)
3.по структуре реализации алгоритма (структурное или блочное)
4.по использованию функций (с функциями или без функций)
====
по типу логики решения задания существуют:
1.редукция — когда известны исходные данные и как их надо преобразовать — известно также как нисходящая декомпозиция или пошаговое усовершенствование
2.индукция — когда известен формат результата, формат исходных данных и надо создать алгоритм
3.дедукция — когда есть программа и надо понять смысл её работы — для этого надо абстрагировать алгоритм программы в автомат
в ходе программирования эти типы могут комбинироваться
для каждого типа программирования существует свой тип проверки правильности алгоритма программы
1.для редукции:
— берутся значения для которых известны правильные результаты и сравниваются с результатами программы
— строится обратная функция и по ней проверяются результаты программы
2.для индукции: берутся крайние значения и точки экстремума функций формата исходных данных и сравнивается результат работы программы с требуемым форматом исходных данных
3.для дедукции: представляется алгоритм программы как автомат, и определяется изза чего и в каких областях значений срабатывают переходы этого автомата
====
по направлению синтеза решения существуют:
1.программирование «сверху» или конструирование функции
=
достоинства:
1.Хорошо решает проблемы имеющие иерархический характер
2.Большая группа схожих проблем может быть идентифицирована и сгруппирована вместе.
3.Каждая из этих проблем относительно мала и может характеризоваться малым числом параметров.
4.Каждая из проблем отличается от других (иначе говоря, унификация требует многократного использования проекта и его кода в каждой проблеме).
5.Нет включения сложных структур данных (иначе концептуальная автономия каждого прикладного модуля была бы потеряна).
Области, которые соответствуют этим критериям, включают библиотеки математических подпрограмм для решения проблем линейной алгебры и дифференциально-разностных уравнений.
=
недостатки:
1.Функциональную точку зрения трудно развивать.
Каждая реальная система изменяется и эволюционирует. Нисходящий подход создает хорошую программную модель для исходных требований к системе. Но система изменяется, что ведет к появлению новых требований. Поэтому функциональная архитектура постепенно становится неуправляемой.
Поскольку программное обеспечение разработано вокруг относительно фиксированной древовидной структуры, изменения обычно требуют длительного сокращения и прививания. Чистый и хорошо разработанный проект быстро становится «ужастиком», повествующим о новых и повисших связях. Сопровождение становится все более трудным, поскольку первоначальная архитектура медленно умирает с каждой новацией или изменением требований.
2.Реальные системы трудно охарактеризовать функционально.
Многие из больших систем не имеют верхнего уровня. Например, система управления базой данных включает инструментальные средства для запроса данных, изменение данных, хранение непротиворечивых данных, и т.д. Нет какой-либо функции, являющейся самым важным звеном в этой системе. Определение этой системы в терминах одной функции верхнего уровня искусственно и приводит к чрезмерно сложным и неадаптивным архитектурам.
«Одним из наиболее важных решений, принимаемым при разработке системы, является предположение о том, как сделать декомпозицию верхнего уровня. При нисходящем подходе это решение необходимо принять в начале процесса проектирования, то есть тогда, когда имеется минимум информации. Возможно, наиболее серьезная слабость в том, что нисходящее функциональное проектирование требует, чтобы система характеризовалась одной функцией наверху. Это сомнительное требование для многих современных систем, управляемых событиями».
3.Фокусирование на функциональности теряет из виду данные.
Нисходящий проект не фиксирует информацию о данных, используемых в программе. Функции же всегда что-то делают с данными. Обычно, одни и те же данные разделены между функциями (например, модификации, удаления, вставки и запроса, работающих с таблицей базы данных). Так как декомпозиция только высвечивает функциональные аспекты проблемы, влияние структур данных на проблему оказывается потерянным.
4.Функциональная ориентация производит код, менее пригодный для многократного использования.
При нисходящем проектировании осуществляется непрерывное дробление проблемы на все более простые части. Каждый кусок анализируется и специфицируется отдельно без сильной связи между ним и остальной частью системы. Это является одной из причин, по которой проектирование «сверху вниз» так эффективно на этапе анализа проблемы.
Данный метод работает хорошо при начальном проектировании системы, и помогает получить спецификации для выявления и решения проблемы. Однако каждый элемент программы разработан только с ограниченными требованиями к памяти. Так как маловероятно, что точно такие же требования встретятся при решении следующей проблемы, проект программы и код не могут быть обобщены для многократного использования.
=
проблемы:
1.Когда необходимо иметь дело с более сложными проблемами приходится иметь индивидуальные подпрограммы со многими параметрами
Большое число параметров будет делать подпрограмму трудно используемой и трудно сопровождаемой. Код, скорее всего, будет включать многочисленные вложения операторов if или case. Это кошмар при таких модификациях, как новые добавления к пространству состояний.
2.Когда необходимо иметь дело с более сложными проблемами приходится иметь много малых подпрограмм с небольшим числом параметров.
Большое количество подпрограмм будет затруднять их запоминание, что затрудняет использование. Более того, будет иметься много общего кода, рассеянного среди этих многих подпрограмм (так как многие из них будут очень похожи). Этот общий код будет трудно модифицировать и поддерживать. Библиотеки подпрограмм полезны в некоторых областях, но они не решают общих проблем, присущих синтезу.
3.Синтез не препятствует созданию общих подпрограмм, которые разделяются между многими программами; но оно не поощряет этот процесс.
===
2.программирование «снизу»:
=
достоинства:
1.Хорошо объединеняет повторно используемые программы и подпрограммы в систему
=
недостатки:
1.сложность программы, с увеличением числа переменных, функций и их комбинаций, возрастает в геометрической прогрессии, изза чего:
— сложно запомнить предназначение переменных, функций и адресных меток блоков
— с увеличением количества строк уходит много времени на поиск требуемого текста программы и перемотку к нему
====
по структуре реализации алгоритма существуют:
1.структурное программирование — представление программы в виде одной структуры с ветвением на подструктуры с помощью оператров if, for, case, switch, while, do
2.блочное программирование — представление программы в виде адресованных метками(label) блоков с переходами к ним по оператору goto
==
1.структурное программирование
=
позволяет:
1.возможность легкого заимстования кода в другие программы
2.возможность легкого мелкого улучшения программ
=
создает проблемы:
1.при большой вложенности циклов теряется читабельность программы
2.при большой вложенности циклов неудобно редактировать программу в связи с большим количеством символов отступов показывающих степень вложенности команд в ядре цикла
3.для проверки приходится в мозгу переводить все структуры в автомат
==
2.блочное программирование
=
позволяет:
1.возможность блочного программирования и как подраздел его — программирование автоматов (можно вместо goto использовать switch do и break, но это усложняет программу, теряет её наглядность и увеличивает количество её строк)
2.быструю скорость программирования
3.легкость понимания алгоритма кода
4.легкость проверки кода на корректность работы алгоритмов
5.возможность масштабных переходов, когда можно перейти сразу в конец программы без учета всяких закрывающих ковычек, слабую возможность этого делает break
=
создает проблемы:
1.можно потерять данные
2.можно потерять указатели
3.можно перепутать переменную изза использования одной и той же переменной для разных задач
4.если ваш работадатель узнает что вы в своем коде ставите goto вас могут уволить за якобы непрофессионализм, или если при приёме на работу в вашем тестовом задании увидят goto вам могут отказать в приёме на работу
5.вас могут презирать ваши коллеги программисты за использование goto как непрофессионала
6.ваш заказчик, если кто-нибудь ему сообщит что вы используете goto в программе, может отказать вам в заказе
7.ваша репутация может быть испорчена
====
по использованию функций существуют:
1.программирование с функциями
2.программирование без функций
=
достоинства функций:
1.более понятный текст программы, особенно если название функции описывает её действие
2.более короткий исходный код
3.экономия памяти ОЗУ
=
недостатки функций:
1.изза функций сложно использовать такой мощный инструмент как рекурсия, поскольку работающая со стеком функция использует изза рекурсии слишком много памяти, расходуемой стеком на передачу адреса возврата функции, либо вообще возможна утечка памяти
2.функция — это потеря времени на переходы и работу со стеком, потеря времени на резервное хранение параметров функции, потеря памяти на работу стека функции и её переменных
=====
Основное различие между традиционными структурными методологиями проектирования и более новыми объектно-ориентированными методологиями находится в их первичном фокусировании:
Структурные методы проектирования фокусируются на функциях системы: «Что она делает».
Объектно-ориентированные методы фокусируются на данных (объектах) системы: «Что делается с. «.
Разработка программного обеспечения — это, прежде всего, нахождение способов получения качественного программного продукта
Качество программного обеспечения —
1.внешние характеристики (например, легкое в использовании, выполняется быстро)
2.внутренние характеристики (например, модульная конструкция, читабельный код).
Внешние метрики — единственные, которые, в конце концов, действительно имеют значение. Никто, на самом деле, не заботится, насколько хорошую модульную конструкцию вы использовали при создании программы. Всех только заботит, чтобы она хорошо выполнялась. Однако, внутренняя (скрытая) метрика является ключом к созданию внешних, и при этом необходимо учитывать правила конструирования программ и технику программирования.
Источник: iforum.pro