Вход

Жизненный цикл программного обеспечения

Реферат* по информатике и информационным технологиям
Дата добавления: 01 сентября 2010
Язык реферата: Русский
Word, rtf, 419 кб (архив zip, 46 кб)
Реферат можно скачать бесплатно
Скачать
Данная работа не подходит - план Б:
Создаете заказ
Выбираете исполнителя
Готовый результат
Исполнители предлагают свои условия
Автор работает
Заказать
Не подходит данная работа?
Вы можете заказать написание любой учебной работы на любую тему.
Заказать новую работу
* Данная работа не является научным трудом, не является выпускной квалификационной работой и представляет собой результат обработки, структурирования и форматирования собранной информации, предназначенной для использования в качестве источника материала при самостоятельной подготовки учебных работ.
Очень похожие работы
Содержание Аннотация. Введение. 1. Жизненный цикл ПО Введение. Шаги процесса программирования по Райли Введение. 1.1.1. Постановка задачи. 1.1.2. Проектирование решения. 1.1.3. Кодирование алгоритма. 1.1.4. Сопровождение программы. 1.1.5. Программная документация. Вывод к п. 1.1 1.2. Определение ЖЦПО по Леману. Введение. 1.2.1 Определение системы. 1.2.2. Реализация. 1.2.3. Обслуживание. Вывод к п. 1.2. 1.3. Фазы и работы ЖЦПО по Боэму 1.3.1. Каскадная модель. 1.3.2. Экономическое обоснование каскадной модели. 1.3.3. Усовершенствование каскадной модели. 1.3.4. Определение фаз жизненного цикла. 1.3.5. Основные работы над проектом. Вывод. Литература. Введение Промышленное применение компьютеров и растущий с прос на программы поставили актуальные задачи существенного повышения производительности разработки ПО , разработки индустриальных методов планирования и проектир ования программ, переноса организационно-технических, технико-экономи ческих и социально-психологических приемов, закономерностей и методов из сферы материального производства в сферу применения компьютеров. Комплексный подход к процес сам разработки, эксплуатации и сопровождения ПО выдвинул ряд насущных п роблем, решение которых исключит «узкие места» в проектировании програ мм, уменьшит сроки завершения работ, улучшит выбор и адапт ацию существующих программ, а может быть и определит судьбу с истем со встроенными ЭВМ. В практике разработок больших программных проектов зачастую отсутству ет единый подход к оценивани ю затрат труда, сроков проведения работ и материальных затрат, что сдерж ивает повышение производительности разработки ПО, а в конечном счете – эффективное управление жизненным циклом ПО. Поскольку программа любог о типа становится изделием (кроме, может быть, учебных, макетных программ ), подход к ее изготовлению во многом должен быть аналогичен подходу к про изводству промышленной продукции, и вопросы проектирования программ с тановятся чрезвычайно важными. Эта идея лежит в основе книги Б.У. Боэма «И нженерное проектирование программного обеспечения», которую мы исполь зовали при написании данной курсовой работы. В этой книге под проектированием ПО понимается процесс создан ия проекта программного изделия. 1 Жизненный цикл ПО ВВЕДЕНИЕ ЖЦПО – это непрерывный процесс, который начинаетс я с момента принятия решения о необходимости создания ПО и заканчиваетс я в момент его полного изъятия из эксплуатации. Существует несколько подходов при определении фа з и работ жизненного цикла программного обеспечения (ЖЦПО), шагов процес са программировани я, каскадная и спиральная модел и. Но все они содержат об щие ос новополагающие компоненты: постановка задачи, проектирование решения, реализация, обслуживание. Наиболее известной и полной, пожалуй, является структура ЖЦПО по Боэму, в ключающая восемь фаз. Она и будет представлена в дальнейшем наиболее под робно. Одним из возможных вариантов может послужить описание верхнего уровня по Леману, включающее три основные фазы и представляющее описание ЖЦПО в самом общем случае. И, для разнообразия, – приведем шаги процесса программиро вания, представленные Д.Райли в книге «Использование языка Модула-2». Это представление, по-моему, является весьма простым и привычным, с него и нач нём. 1.1 Ша ги процесса программирования по Райли Введение Процесс пр ограммирования включает четыре шага (р ис. 1 ): постановка задачи, т.е. получение адекватного представления о том, какую задачу должна выполнить программа; проектирование решения уже поставленной задачи (в общем, такое решение является менее формальным, че м окончательная программа); кодирование программы, т. е. перевод спроектированного решения в програм му, которая может быть выполнена на машине; сопровождение программы, т.е. непрекращающийся процесс устранения в про грамме неполадок и добавления новых возможностей. Рис. 1 . Чет ыре шага программирования. Программирование начинается с того момента, когда пользователь , т.е. тот, кто ну ждается в программе для решения задачи, излагает проблему системному аналитику. Пользователь и с истемный аналитик совместно определяют постановку задачи. Последняя з атем передается алгоритмисту , который отвечает за проектирование решения. Решение (или алг оритм) представляет последовательность операций, выполнение которых п риводит к решению задачи. Поскольку алгоритм часто не приспособлен к вып олнению на машине, его следует перевести в машинную программу. Эта опера ция выполняется кодировщиком. За последующие изменения в программе нес ет ответственность сопровождающий программист. И системный аналитик, и алгоритмист, и кодировщи к, и сопровождающий программист – все они являются программистами. В случае большого программного проекта число пользователей, системных аналитиков и алгоритмистов может оказаться значительным. Кроме того, мо жет возникнуть необходимость вернуться к предшествующим шагам в силу н епредвиденных обстоятельств. Все это служит дополнительным аргументом в пользу тщательного проектирования программного обеспечения: резуль таты каждого шага должны быть полными, точными и понятными. 1.1.1 Постановка задачи Одним из на иболее важных шагов программирования является постановка задачи. Она в ыполняет функции контракта между пользователем и программистом (прогр аммистами). Как и юридически плохо составленный контракт, плохая постано вка задачи бесполезна. При хорошей постановке задачи как пользователь, т ак и программист ясно и недвусмысленно представляют задачу, которую нео бходимо выполнить, т.е. в этом случае учитываются интересы как пользоват еля, так и программиста. Пользователь может планировать использование е ще несозданного программного обеспечения, опираясь на знание того, что о но может. Хорошая постановка задачи служит основой для формирования ее р ешения. Постановка задачи ( спецификация программы ); по существу, означает точное, полное и понятное описание того , что происходит при выполнении конкретной программы. Пользователь обыч но смотрит на компьютер, как на черный ящик: для него неважно, как работает компьютер, а важно, что может компьютер из того, что интересует пользоват еля. При этом основное внимание фокусируется на взаимодействии человек а с машиной. Характеристики Хорошей Постановки Задачи: Точность , т.е. исключение люб ой неоднозначности. Не должно возникать вопросов относительно того, как им будет вывод программы при каждом конкретном вводе. Полнота , т.е. рассмотрение вс ех вариантов для заданного ввода, включая ошибочный или непредусмотрен ный ввод, и определение соответствующего вывода. Ясность , т.е. она должна быть понятной и пользователю и системному аналитику, поскольку постановка з адачи – это единственный ко нтракт между ними. Часто требование точности, полноты и ясности находятся в противоречии. Т ак, многие юридические документы трудно понять, потому что они написаны на формальном языке, который позволяет предельно точно сформулировать те или иные положения, исключая любые самые незначительные разночтения. Например, н екоторые вопросы в экзаменационных билетах иногда сформулированы настолько точно, что с тудент тратит больше времени на то, чтобы понять вопрос, чем на то чтобы на него ответить. Более того, ст удент вообще может не уловить основной смысл вопроса из-за большого коли чества деталей. Наилучшая постановка задачи та, при которой достигается баланс всех трех требований. Стандартная форма постановки задачи. Рассмотрим следующую постановку задачи: «Ввести три числа и вывести чис ла в порядке». Такая постановка не удовлетворяет приведенным выше требованиям: она не является ни точной, ни полной, ни понятной. Действительно, должны ли числа вводиться по одному на строке или все числа на одной строке? Означает ли в ыражение «в порядке» упорядочение от большего к меньшему, от меньшего к большему или тот же порядок, в каком они были введены. Очевидно, что подобная постановка не отвечает на множество вопросов. Есл и же учесть ответы на все вопросы, то постановка задачи станет многослов ной и трудной для восприятия. Поэтому Д. Райли предлагает для постановки задачи пользоваться станда ртной формой, которая обеспечивает максимальную точность, полноту, ясно сть и включает: наименование задачи (схематическое определение); общее описание (краткое изложение задачи); ввод; вывод; ошибки (явно перечислены необычные варианты ввода, чтобы показать польз ователям и программистам те действия, которые предпримет машина в подоб ных ситуациях); пример (хороший пример может передать сущность задачи, а также проиллюст рировать различные случаи). Пример. Постановка задачи в стандартной форме. НАЗВАНИЕ Сортировка трех целых чисел. ОПИСАНИЕ Ввод и вывод трех целых чисел, отсортированных от меньшего числа к больш ему. ВВОД Вводятся три целых числа по одному числу на строке. При этом целым числом является одна или несколько последовательных десятичных цифр, которым может предшествовать знак плюс «+» или знак минус «– ». ВЫВОД Выводятся три введенных целых числа, причем все три выводятся на одной с троке. Смежные числа разделяются пробелом. Числа выводятся от меньшего к большему, слева направо. ОШИБКИ 1) Если введено менее трех чисел, программа ждет дополнительного ввода. 2) Строки ввода, кроме первых трех, игнорируются. 3) Если какая-либо из первых трех строк содержит более одного целого числа , то программа завершает работу и выдает сообщение. ОШИБКА ВВОДА – допускается только одно целое число на строке. ПРИМЕР: ввод – 3 2 + 17 вывод – 3 2 + 17 1.1.2. Проектирование решения Этот шаг пр ограммирования является наиболее трудным. На данной стадии постановка задачи должна быть превращена в алгоритм. Поэтому алгоритмист должен об ладать достаточным опытом программирования и подходить к каждой новой задаче, опираясь на твердо установленную методику проектирования. К сож алению, в настоящее время все большие программы содержат ошибки, что при водит к скверным проектам. Плохие проекты в свою очередь являются следст вием сложности задач и использования неадекватных методов проектирова ния. Чтобы избежать ошибок в программах, алгоритмисты должны использова ть тщательно разработанные процедуры конструирования, основанные на п равилах логического вывода. Существуют две основные модели вывода: Первая модель известна как дедуктивный вывод. Эту форму логического мышления обессмертил знаме нитый сыщик Шерлок Холмс. Дедуктивная логика применяет общие правила к к онкретным случаям. Например, Холмс мог вывести конкретное утверждение « Дворецкий является убийцей» из более общих сведений «Убийца-блондин», а «Дворецкий является единственным блондином, которого можно подозреват ь». Вторая модель – это индуктивный вывод, который являетс я противоположностью дедуктивному выводу . Индуктивная логика извлекает общие заключения из отдель ных случаев. Например, индуктивный вывод может быть использован, чтобы о босновать общее заключение «солнце поднимается на востоке» на основан ии многих отдельных наблюдений того, что солнце всегда поднималось на во стоке. Эти два процесса вывода умозаключений – дедукция (от о бщего к частному) и индукция (от частного к общему) – тесн о связаны с двумя наиболее широко распространенными методами проектир ования: «сверху вниз» и «снизу вверх». Подобно дедукции , проектирование «сверху вниз» начинается с большой задачи, которая разб ивается на подзадачи. Например, проектировщик нового холодильника-моро зильника на основании исходного множества спецификаций агрегата (т.е. по становки задачи) должен дать детальные схемы и спецификации окончатель ного продукта (т.е. проект). Если при этом он использует метод проектирования «сверху вниз», то единс твенная задача проектирования может быть разбита на две меньшие подзад ачи: (1) проектирование холодильного агрегата и (2) проектирование морозиль ника. Однако можно воспользоваться методом проектирования «снизу вверх» и н ачать с проектирования холодильного компрессора, а затем охлаждающих т руб, агрегата или холодильной камеры. В таком случае этот выбор будет нал агать определенные ограничения на весь проект. Задача проектировщика – соз дание алгоритма, выполняющего функции связующего звена между постанов кой задачи и готовой для исполнения программой. Проверку созданного алг оритма, т. е. насколько последний отражает постановку задачи, осуществля ет системный аналитик. В силу этого и системный аналитик, и проектировщи к должны уметь читать и понимать алгоритм. Каждый алгоритм записывается на некотором псевдоязыке . А лгоритмы, называемые также псевдокодами, не могут быть выполнены ни на к аком компьютере. 1.1.3 Кодиров ание алгоритма Работа коди ровщика заключается в переводе алгоритма в программу. Для создания полн ой, точной и понятной программы необходимы соответств ующие методы записи программ. Например, к улинарные рецепты обычно записываются на естественных язык ах, таких, как английский, французский, русский или японский. Программы же пишутся на языках программирования. В настоящее время ни один из естеств енных языков нельзя использовать в качестве языка программирования, та к как они чересчур сложны, чтобы их могли «понимать» машины. В отличие от е стественных , языки программи рования созданы специально для такого представления решения задачи, ко торое может быть выполнено компьютером. 1.1.4 Сопрово ждение программы Прежде чем завершить работу, кодировщик должен убедиться, что программа соответст вует псевдокоду. Затем системный аналитик, алгоритмист и, что самое глав ное, пользователь должны протестировать и подтвердить, что она работает правильно. После этого можно считать, что программа готова для передачи пользователю в комплекте со всей необходимой документацией. Однако на этом программирование не заканчивается; далее следует шаг сопровождения. Дело в том, чт о в программе могут быть ошибки, обусловленные либо неадекватной постан овкой задачи, либо тем, что проект не удовлетворяет постановке задачи ил и программа не соответствует проекту. Какова бы ни была причина, пользов атель вправе потребовать корректировки программы, поскольку он не пред ставлял, что программа будет работать таким образом. Исправление ошибок является одной из главных задач сопровождения программ. Другой не менее важной задачей сопровожден ия программ является ее модификация, т. е. добавление в программу новых во зможностей или изменение существующих. Пользователь может изменить тр ебования к работе программы, что, в свою очередь, приведет к необходимост и ее переписать. Сложность операций по сопровождению программы зависит от типа изменений, которые должны быть сделаны: в худшем случае может пот ребоваться полная переработка программы от постановки до кодирования. Обычно на сопровождение программы затрачивается большее время, чем на е е создание. 1.1.5 Програм мная документация Последней с оставляющей процесса программирования является документирование. Оно включает широки й спектр описаний, облегчающих процесс программирования и обогащающих результирующую программу. Постоянное документирование должно составл ять неотъемлемую часть каждого шага программирования. Постановка зада чи, проектные документы, алгоритмы и программы – все это документы. Внутренняя документация, включен ная непосредственно в программу, облегчает чтение кода. Назначение учеб ного пособия (еще одной формы документации) – научить пользователя применять новую программу; справ очное руководство позволяет ознакомиться с описанием команд программн ого обеспечения. Вывод к п.1.1. Согласно мо дели, представленной в данной главе, программирование можно разделить н а четыре шага: постановку задачи, проектирование решений, кодирование пр ограммы, сопровождение программы. Дополнительно модель включает докум ентирование программы как действия, которые необходимо выполнять в теч ение всего процесса программирования. Модель программирования построена специально для решения больших проб лем, так как именно они представляют интерес для специалистов в области информатики. Тем не менее, на практике важно использовать тщательно выбр анные инженерные методики проектирования программ независимо от разме ра задач: навыки, приобретенные в процессе решения более мелких задач, мо гут быть закреплены и успешно реализованы при решении больших задач. Следует помнить, что хорошее программирование – это не кодирование быстро найденного решения с п омощью любой подходящей методики, а тщательно инструментированная инж енерная процедура, позволяющая создать полное, точное и легко понимаемо е (ясное) программное обеспечение. 1.2 Определение ЖЦПО по Леману Введение В самом общ ем случае можно считать, что жизненный цикл программной системы состоит из трех фаз: определения; реализации; обслуживания. 1.2.1 Определение системы Процесс создания ПО начинается с практических изыскани й, ведущих к системному анализу, задача которого состоит в определении о бщих требований к системе и программам. Такой анализ должен, прежде всег о, установить реальные потребности и цели и по возможности выявить имеющ иеся методы, позволяющие достичь поставленной цели. При необходимости а нализ может основываться на математических или иных формальных схемах. Считается, что при любом подходе указанный анализ должен иметь определе нную структуру и проводиться в соответствии с некоторой теорией. Анализ и внесение уточнений, осуществля емые совместно с аналитиками и потенциальными пользователями, должны п ривести к выработке окончательной спецификации требований . Процесс составления такой спецификации имеет целью получение правильн ого технического задания, полного в смысле отражения требований и согла сованного с определением реализации. За составлением спецификаций следует фаза проектирования, смысл которой состоит в идентификации и структуризации данных, их преобразовании и организац ии их передачи. Кроме того, на этой фазе необходимо добиться в определенн ом смысле оптимального распределения функции системы, выбрать алгорит м и процедуры, а также обозначить системные компоненты и связь между ним и. 1.2.2 Реализа ция Завершив проектирование можно начин ать реализацию системы. Одн ако на практике фаза проектирования и реализации перекрываются. Таким о бразом, по мере осуществления иерархического процесса разбиения анали з некоторых элементов системы может быть признан достаточно полным для перехода к реализации, в то время как другие элементы требуют дальнейшег о уточнения. В ходе процесса реализации необходимо устанавливать правильность прог раммы. Современные процедуры большей частью основаны на тестировании, х отя в последние годы расширилось использование методов сквозного стру ктурного контроля и аттестации программ. В любом случае, тестирование посредством исполнения программы обычно о существляется снизу вверх, в начале на блочном (модульном или процедурно м уровне), затем функционально, компонент за компонентом. По мере проверк и отдельных компонентов они объединяются в систему в процессе ее компон овки, после чего начинаются системные испытания. В конечном итоге, после того как независимо будет удостоверено качество функционирования сист емы и оценены ее параметры, она считается готовой к выпуску. 1.2.3 О бслуживание Процесс обс луживания начинается сразу после выпуска системы. Ошибки подлежат выяв лению и исправлению. Если нормальной работе пользователя препятствует ошибка, то ошибочную программу можно временно исключить из системы или ж е внести временные или постоянные исправления в некоторые или во все исп ользуемые системы. Постоянное исправление или изменение можно затем вн ести в новый выпуск системы. Для того чтобы учесть все изменения и их комб инации, создаются многочисленные версии системных элементов. Главной з адачей становится управление системной конфигурацией. Решающая роль в управлении программирования принадлежит вспомогательным службам, кот орые автоматически собирают и регулируют все изменения в системе. Вывод к п.1 .2. Метасистем а, в рамках которой развивается программа, содержит существенно большее количество контуров обратной связи, чем указано выше. Многие виды деятел ьности перекрываются, сложным образом переплетаются и систематически повторяются. Поэтому достаточно обоснована модель ЖЦПО представленная Боэмом. 1.3 Фазы и работы ЖЦПО по Боэму 1.3.1 Каскадная модель Каскадная м одель была введена в 70 – 80 гг. Она удобна для однородных ПП, когда каждое пр иложение представляло собой единое целое. Основные характеристики модели: - Жизненный цикл разбивается на этапы (фазы); - Переход с этапа на этап – только после полного завершения текущего эта па; - Этап завершается выпуском полного комплекта документации, достаточно й для того, чтобы работа могла быть выполнена другой командой разработчи ков. Главные хар актерные черты каскадной модели следующие: завершение каждой фазы верификацией и подтверждением, цель которых – у странить возможно большее число проблем, связанных с разработкой издел ия; циклические повторения реализованных фаз с возможно более ранней фазы. Рис.2 . Каскадная модель ЖЦПО. В каскадной модели успешное окончание одной из фаз ЖЦПО означает достижение соотве тствующей цели инженерного программирования (см. п. 2.4.). К этим подцелям нео бходимо добавить еще две: Детальная проектируемость – получение полных верифицированных спецификаций и структур управлен ия и данных, интерфейсных связей, характеристик, основных алгоритмов и о пределение условий работы каждого программного компонента. Кодируемость – получение полного, верифицированного набора компонентов программы. Основные достоинства: Формирование полного набора проектной документации в конце работы над этапом. Документация отвечает критериям полноты и завершенности; Возможность планирования сроков и затрат. Для целого ряда ПП эта модель реализуема – это для систем, для которых на этапе анализа можно точно и п олно сформировать все требования. Например, сложные вычислительные про граммы. Основные недостатки: - Большие сроки от анализа до завершения; - Требования к ПО «заморожены» в виде ТЗ до конца разработки . 1.3.2 Экономическое обоснование каска дной модели Не углубляя сь в экономический анализ, которому Б.У. Боэм уделяет большое внимание в книге «Инженерное проектиро вание программного обеспечения», скажем лишь, что экономическое обосно вание каскадной модели, ориентированной на последовательное достижени е целей, базируется на двух главных предпосылках: Для получения качественного программного изделия (т.е. такого, которое в полной мере удовлетворяет всем целям требуемого программного изделия) необходимо в любом случае осуществить все подцели на каждом этапе. Любое другое упорядочение подцелей приводит к созданию менее качестве нного программного изделия. 1.3.3 Усовершенствование каскадной мо дели Рассмотрим одно из усовершенствований идеальной каскадной модели – пошаговую разработку. Пошаговая разработка являе тся усовершенствованием метода повторной разработки с созданием прото типа и поуровневой разработкой сверху – вниз. Этот метод предполагает пошаговое увеличение функци ональных возможностей ПО в процессе разработки. В качестве усовершенствованной каскадной модели пошаговая разработка успешно применялась при создании как очень больш их, так и небольших программных изделий. Главными преимуществами пошаговой разработки перед абсолютно повторн ой разработкой и поуровневой разработкой сверху – вниз являются следу ющие: использование последовательных расширений программы обеспечивает го раздо менее дорогой способ учета в усовершенствованном изделии опыта п ользователей, чем при повторной разработке; расширение функциональных возможностей намного упрощает проверку и по лезнее, чем промежуточные изделия при поуровневой разработке. Значение пошаговой разработки заключается главным образом в изменении распределения затрат труда на проект. Вариант каскадной модели при поша говой разработке показан на рисунке 3. 1.3.4 Определение фаз жизненного цикла Ниже будут даны формулировки конечных целей каждой фазы для перехода к следующей ф азе. Для пошаговой разработки приводимые формулировки относятся к гран ицам фаз каждого шага расширения. Начать фазу планирования и анализа требований. (Завершение концептуального обзора ЖЦПО.) Получение одобренной и подтвержденной архитектуры системы с включение м основных соглашений о распределении функций между аппаратурой и программами. Получение одобренн ого и подтвержденного общего представления о б функционировании ПО с включением основных соглашени й о распределении фун кций между человеком и систем ой. Ф ормирование общего плана ЖЦПО с определением осн овных этапов, ресурсов, обязанностей, сроков и главных работ. Завершить фазу планирования и анализа требовани й. Начать фазу проектирования изделия. (Завершение обзора требований к ПО). Ф ормирование детального пла на разработки: детальных показателей завершения этапов разработки, пла нов распределения ресурсов, схем организационной структуры, обязаннос тей, сроков, работ, методов и изделий. Формирование детального плана использования: пунктов плана разработки , содержание которых ориентировано на обучение, перенос программ, внедре ние, эксплуатацию и поддержание. Формирование детального плана отладки изделия – план управления конфигурацией технического обе спечения, план контроля качества, общий план верификации и подтверждени я. Одобренная и подтвержденная спецификация требований к ПО: функциональ ные, технические и интерфейсные спецификации, для которых подтверждены их полнота, непротиворечивость, проверяемость и осуществимость. Одобренный (формально или неформально) договор на разработку, основанны й на приведенных выше пунктах. Закончить фазу проектирования изделия. Начать фа зу детального проектирования. (Завершение анализа результатов проектирования изделия.) Разработка верифицированной спецификации проекта программного издел ия: формирование иерархии программных компонентов, межблочных интерфейсо в по данным и управлению; формирование физической и логической структур данных до уровня отдель ных полей; разработка плана распределения вычислительных ресурсов (времени, памя ти, точности); верификация полноты, непротиворечивости, осуществимости и обоснованно сти требований. Установление и разрешение всех противоречий разработки, которые повыш ают степень риска. Разработка предварительного этапа комплексирования и отладки, плана р уководства для пользователей и приемных испытаний. Закончить фазу детального проектирования. Начат ь фазу кодирования и автономной отладки. (Завершен ие сквозного контроля проекта или критического поблочного анализа про екта.) Верифицированная детальная спецификация каждого блока: спецификация каждой подпрограммы, имени, назначения, предположений, раз меров, последовательности вызовов, ошибочных выходов, входных и выходны х данных, алгоритмов и логической схемы; описание базы данных до уровня отдельных параметров, символов и битов; верификация полноты, непротиворечивости и соответствия требованиям пр оектных спецификаций системы и планам распределения ресурсов. Одобренный план приемных испытаний. Руководства пользователю, а также завершенный предварительный план ко мплексирования и отладки. Закончить фазу копирования и отладки. Начать фаз у комплексирования и отладки. (Удовлетворение крит ериев автономной отладки.) Проверка работы всех блоков не только для номинальных, но также для искл ючительных и предельных значений. Проверка всех вариантов ввода и вывода, включая сообщения об ошибках. Выполнение всех операторов и всех ветвей передачи управления. Проверка выполнения стандартов программирования. Завершение поблочного документирования внутренней структуры. Закончить фазу комплексирования и испытаний. Нач ать фазу внедрения. (Завершение анализа результато в приемных испытаний.) Проверка удовлетворения тесту приемных испытаний программ: проверка удовлетворения требованиям к ПО; демонстрация приемлемости указанных в спецификациях характеристик работы в нештатных условиях. Приёмка поставляемых программных изделий, отчетов, руководств, баз данн ых, спецификаций внутренней структуры. Закончить фазу внедрения. Начать фазу эксплуатац ии и сопровождения. (Завершение анализа приемки си стемы.) Проверка удовлетворительности результатов приемных испытаний систем ы. Проверка удовлетворительности системных требований. Проверка производственной готовности ПО, аппаратуры, средств обслужив ания и персонала. Приёмка поставляемых и входящих в систему изделий: аппаратуры, ПО, докум ентации, средств обучения и обслуживания. Завершение всех специфи ци ро ванных работ и ввод системы в действие. Закончить фазу эксплуатации и сопровождения (путем снятия с производства). Выполнение всех пунктов плана снятия с производства: перенос программ, д окументирование, создание архива, переход к новой системе. 1.3 .5 Основные р аботы над проектом Анализ треб ований. Проектирование изделия. Программирование. Планирование отладки. Верификация и подтверждение. Управление проектом. Управление конфигурацией и контроль качества. Документирование. Вывод Итак, были р ассмотрены три подхода к определению жизненного цикла ПО. На мой взгляд, все они имеют право на существование, так как в той или иной степени отраж ают практику программирования. Тем более, что легко можно обнаружить общ ие моменты (ставится задача – определяется система – ан ализируются требования; сопровождение программы – обслуживание – эксплуатация и сопровождение). Однако, надо заметить, что определение фаз и работ ЖЦПО Боэма наиболее об осн ованно, т.к. опирается на более ориентированный подход в инженерном программировании (напр авленный на получение качественного программного изделия и реализацию эффективного процесса разработки и сопровождения ПО) и обосновывается экономически. Исходя из данного отчета видно как важно и необходимо знать потребности соврем енного мира при составлении программного продукта (изделия). Важно при с оставлении программы для автоматизации, какой либо системы, учитывать то, что современный мир пост оянно меняется, а значит должна быть способной к изменению и программа. Важно так же, при составлении программы, учитывать то, что программа долж на быть точной; полной по своему содержанию и пригодной для работы как с м аленькими, так и с большими проблемами в соответствии со своим предназна чением; ясной - для того чтобы пользователь мог спокойно, без затруднений работать с ней. А так же чтобы программу в любой момент можно было бы легко исправить или дополнить в соответствии с изменившимися т ребованиями в современном мире. Следует помнить, что хорошее программирование – это не кодирование быстро найденного решения с п омощью любой подходящей методики, а тщательно инструментированная инж енерная процедура, позволяющая создать полное, точное и легко понимаемо е (ясное) программное обеспечение. Литература 1. Б.У. Боэм «Инженерн ое проектирование программного обеспечения». М.: Радио и связь. 1985. 2. Д.Райли. «Использование языка Мод ула-2». М.: Мир. 1993. 3. Ю.В. Иванов «Программы и их жизненные циклы» (реферат по дисци плине «Метрология ПО»). 1998.
© Рефератбанк, 2002 - 2024