Курсовая работа по ПИ. пояснительная записка. 1 Общая часть 1 Классификация программных средств

• Название: 1 Общая часть 1 Классификация программных средств
• Анкор: Курсовая работа по ПИ
• Дата: 15.03.2023
• Размер: 311.57 Kb.
• Имя файла: пояснительная записка.docx
• Тип: Документы; #991255

1 Общая часть

1.1 Классификация программных средств

Совокупность программ и сопровождающей их документации, предназначенная для решения задач на ПК, называется программным обеспечением (ПО) (software). Программное обеспечение делится на системное и прикладное.

Программное обеспечение, необходимое для управления компьютером, для создания и поддержки выполнения других программ пользователя, а также для предоставления пользователю набора всевозможных услуг, называется системным программным обеспечением (system software).

Системное программное обеспечение можно классифицировать следующим образом: операционные системы, сервисные системы, программно-инструментальные средства и системы технического обслуживания (Схема 1).



Схема 1 – Классификация ПО ЭВМ

В наборе системных программных продуктов главное место занимают операционные системы (operating system). Операционная система (ОС) - совокупность программ, управляющих работой всех устройств ПК и процессом выполнения прикладных программ. ОС берет на себя выполнение таких операций, как контроль работоспособности оборудования ПК; выполнение процедуры начальной загрузки; управление работой всех устройств ПК; управление файловой системой; взаимодействие пользователя с ПК; загрузка и выполнение прикладных программ; распределение ресурсов ПК, таких, как оперативная память, процессорное время и периферийные устройства между прикладными программами.

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

Главными отличительными чертами современных операционных систем являются:

• 
  многозадачность - способность обеспечивать выполнение нескольких программ одновременно;
  
• 
  развитый графический пользовательский интерфейс;
  
• 
  использование всех возможностей, предоставляемых современными микропроцессорами;
  
• 
  устойчивость в работе и защищенность;
  
• 
  полная независимость от аппаратуры (поддержка всех видов дисплеев и принтеров);
  
• 
  совместимость со всеми видами приложений, разработанных для MS DOS.
  

1.2 Жизненный цикл прикладной программы

Жизненным циклом программы (ЖЦП) на отрезок времени от принятия решения о необходимости разработки программы до снятия программы с эксплуатации. ЖЦП делится на фазы разработки и использования. Первой фазе соответствует разработка документации, а второй сопровождение. Под сопровождением понимают два вида работ:

1. Модификация программы за счет изменения модели предметной области.

2. Нахождение и исправление ошибок, которые есть в программе. В свою очередь фаза разработки делится на 4 под фазы:

1. Анализ задачи.

2. Проектирование.

3. Кодирование.
4. Тестирование.

Каждый период заканчивается своей документацией.

1. Техническое задание.

2. Эскизный, технический проекты, пояснительная записка.

3. Распечатка программы и статическое тестирование.

4. Сборка программы, программа тестирования, результаты

5. Тестирования.

Разработка ПО может вестись с использованием лавинообразной (Схема 2) или итеративной (Схема 3) моделей разработки. Лавинообразная модель (модель "водопада") может быть использована для разработки ПО небольшого размера с хорошо определенной алгоритмической базой.



Схема 2 – Лавинообразная модель

Итеративный подход в разработке программного обеспечения - это выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы. Проект при этом подходе в каждой фазе развития проходит повторяющийся цикл:

• 
  планирование;
  
• 
  реализация;
  
• 
  проверка;
  
• 
  оценка.
  

Схема 3 – Итеративная модель

Преимущества итеративного подхода:

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

• 
  раннее обнаружение конфликтов между требованиями, моделями
  
• 
  более равномерная загрузка участников проекта;
  

• 
  эффективное использование накопленного опыта;
  

• 
  реальная оценка текущего состояния проекта и, как следствие, большая уверенность заказчиков и непосредственных участников в его успешном завершении.
  

1.3 Методология и технология разработки ПП

Методология - это система принципов и способов организации и построения теоретической и практической деятельности, а также учение об этой системе. Самой важной целью методологии программирования является изучение и внедрение таких методов проектирования программ, которые облегчают задачу сопровождения программ. Легкость сопровождения - это такое качество программы, которое нельзя улучшить после ее разработки никакими другими способами, кроме перепрограммирования.

Методология науки дает характеристику компонентов научного исследования - его объекта, предмета анализа, задачи исследования, совокупности исследовательских средств, необходимых для решения задачи данного типа, а также формирует представление о последовательности движения исследователя в процессе решения задачи. Методология создания информационных систем заключается в организации процесса построения информационной системы и обеспечении управления этим процессом для того, чтобы гарантировать выполнение требований как к самой системе, так и к характеристикам процесса разработки. При разработке или приобретении программных продуктов встает проблема формулирования бизнес-требований, предъявляемых к программному продукту или услуге. В значительной степени ошибки проектирования обусловлены неточным выражением этих требований. Разработка программного обеспечения - Software Development Process рассматривается как проектная деятельность, предполагающая дискретность выполнения отдельных шагов (итераций), использование различного вида ресурсов (трудовых, материальных, финансовых, информационных). Проект по созданию программного продукта обладает рядом характеристик, которые влияют на выбор методологии и инструментальных средств разработки.

Сформировалось три стратегии разработки программных продуктов:

1. Линейная последовательность этапов разработки, предполагающая однократный проход этапов процесса разработки; поддерживается "водопадной" моделью жизненного цикла программного продукта.

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

3. Эволюционная стратегия, когда в начале требования определяются в неполном объеме, но уточняются в ходе разработки версий программного продукта. Линейная последовательность этапов разработки имеет несколько вариантов. Модель водопада (Waterfall Model) - наиболее "старая" модель процесса разработки программного обеспечения. Процесс разработки представляется как последовательность (поток) этапов, фаз (анализа требований, проектирования, реализации, тестирования, интеграции и поддержки). Разработчик переходит от одной стадии к другой строго последовательно, после полного и успешного завершения предыдущей фазы; переходов назад либо вперед или перекрытия фаз не происходит. Системный анализ определяет роль каждого элемента в компьютерной системе, взаимодействие элементов друг с другом. Анализ начинается с определения требований и назначения подмножества этих требований программному элементу. Среди основных решаемых задач планирования проекта программного обеспечения выделяют: объем, сроки и трудозатраты проектных работ, бюджет проекта, состав исполнителей, план-график работ. В процессе анализа требований уточняются функции и характеристики программного средства, требования к пользовательскому и программному интерфейсам. Проектирование программного продукта включает в себя разработку архитектуры построения, состава и назначения модулей, алгоритмов и структуры данных, интерфейсов. Кодирование обеспечивает реализацию проектных решений в выбранной среде программирования. Тестирование - обязательный этап для выявления дефектов программного продукта. Сопровождение - поддержка работоспособности программного продукта у заказчика, внесение изменений в эксплуатируемый программный продукт. Каждая стадия (этап) завершается выпуском полного комплекта документации. Эта модель обладает как достоинствами, так и недостатками. Основная проблема - нарастание риска проекта из-за накапливания ошибок ранних стадий проекта, что не позволяет эффективно выявлять и нивелировать последствия подобных рисков.



Схема 4 – Этапы разработки ПО водопадной модели

Модифицированные модели водопада - Agile Software Development, гибкая или "живая" методология разработки, нацелена на минимизацию рисков путем сведения разработки к серии коротких циклов, называемых итерациями, длительностью не более двух недель. Каждая итерация обеспечивает прохождение всех фаз проекта, обеспечивая инкремент (прирост) функциональности. Однако итерация, как правило, недостаточна для выпуска новой версии продукта. По окончании итерации команда разработчиков оценивает и выбирает приоритеты разработки. 

Эта модель предусматривает:

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

Модель RAD может принимать одну из трех форм: макет (в виде чертежа формы документа, схемы диалога), работающий макет для ограниченного набора функций или типовой программный продукт, подлежащий настройке. Макетирование основывается на многократном повторении итераций, в которых участвуют заказчик и разработчик, и начинается со сбора и уточнения требований к создаваемому программному продукту.

Инкрементная модель объединяет элементы последовательной водопадной модели с итерационной основой макетирования.



Схема 5 – Модель RAD

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

1. Планирование - определение целей, вариантов, ограничений;

2. Анализ риска - анализ вариантов и распознавание (выбор) риска;

3. Конструирование - разработка продукта следующего уровня;

4. Оценивание - оценка заказчиком текущих результатов разработки.

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

Спиральная модель ориентирована на большие, дорогостоящие и сложные проекты. При этом требуется:

1. Постоянное взаимодействие с потенциальными пользователями, выяснение изменяющихся требований к программной системе;

2. Разработка архитектуры системы, определяющей концепцию построения программного продукта, открытой для изменений;

3. Наличие разработчиков высокой квалификации, инструментария разработки, соответствующего масштабу и сложности программного продукта.



Схема 6 – Спиральная модель

1.4 Тестирование программных средств

Многие организации, занимающиеся созданием программно­го обеспечения, до 50% средств, выделенных на разработку про­грамм, тратят на тестирование, что составляет миллиарды дол­ларов по всему миру в целом. И все же, несмотря на громадные капиталовложения, знаний о сути тестирования явно не хватает, и большинство программных продуктов неприемлемо, ненадеж­но даже после «основательного тестирования».

О состоянии дел лучше всего свидетельствует тот факт, что большинство людей, работающих в области обработки данных, даже не могут правильно определить понятие «тестирование», и это на самом деле главная причина неудач. Если попросить лю­бого профессионала определить понятие «тестирование» либо открыть (как правило, слишком краткую) главу о тестировании любого учебника программирования, то скорее всего можно встре­тить такое определение:

«Тестирование — процесс, подтверждающий правильность программы и демонстрирующий, что ошибок в программе нет». Основной недостаток подобного определения заключается в том, что оно совершенно неправильно; фактически это почти опреде­ление антонима слова «тестирование». Поэтому определение опи­сывает невыполнимую задачу, а так как тестирование зачастую все же выполняется с успехом, по крайней мере с некоторым ус­пехом, то такое определение логически некорректно. Правиль­ное определение тестирования таково:

Тестирование — процесс выполнения программы с намерением найти ошибки.

Тестирование оказывается довольно необычным процессом (вот почему оно и считается трудным), так как это процесс раз­рушительный. Ведь цель проверяющего — заставить программу сбиться. Он доволен, если это ему удается; если же программа на его тесте не сбивается, он не удовлетворен.

Невозможно гарантировать отсутствие ошибок в програм­ме; в лучшем случае можно попытаться показать наличие оши­бок. Если программа правильно ведет себя для значительного набора тестов, нет оснований утверждать, что в ней нет ошибок; со всей определенностью можно лишь утверждать, что неизвест­но, когда эта программа не работает. Конечно, если есть причи­ны считать данный набор тестов способным с большой вероят­ностью обнаружить все возможные ошибки, то можно говорить о некотором уровне уверенности в правильности программы, ус­танавливаемой этими тестами.

О тестировании говорить довольно трудно, поскольку, хотя оно и способствует повышению надежности программного обес­печения, его значение ограничено. Надежность невозможно вне­сти в программу в результате тестирования, она определяется правильностью этапов проектирования. Наилучшее решение про­блемы надежности — с самого начала не допускать ошибок в про­грамме.