Программные средства

Содержание

Введение

1. Внешнее описание программного средства

2. Методы проектирования программных средств

3.Жизненный  цикл программного средства

4. Качество и надежность программного средства
5. Методы борьбы со сложностью программного средства
6. Практическая часть

Заключение

Список  литературы 
 
 
 

 

Введение

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

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

      Процесс создания ПС в настоящее время все больше приобретает черты индустриального производства. Это объясняется массовой потребностью в ПС и необходимостью «отчуждения» программного продукта от разработчика и потребностью в простоте последующих модификаций программ у потребителя.

     Существует несколько  методов  проектирования программ: нисходящее, структурное и модульное. Целью  которых является сокращение  трудовых и стоимостных затрат  на получение готовых ПС.

     Технологический процесс разработки  и эксплуатации ПС

отражает их «жизненный цикл»,т.е. временной интервал с момента зарождения программы до момента полного отказа от ее эксплуатации .

     В процессе внедрения и эксплуатации  ПС могут выявляться различного  рода ошибки. Обязательным шагом в процессе разработки ПС должна бать проверка правильности принятых решений.  Это позволит обнаружить и исправить ошибки на самой ранней стадии после ее возникновения.      

 

1. Внешнее описание программных  средств

        Разработчикам больших ПС приходиться  решать весьма трудные проблемы,

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

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

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

       Исходным документом для разработки  внешнего описания ПС является  определение требований к ПС.

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

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

Внешнее описание ПС

=

определение требований

+

спецификация качества ПС

+

функциональная  спецификация ПС

 

      Внешнее описание должно достаточно  точно и полно определять задачи, которые должны решить разработчики  требуемого ПС. В то же время оно должно быть понято пользователем. Принимается окончательное решение на заключение договора на разработку ПС.

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

 

2. Методы проектирования ПС

         Существует несколько методов проектирования программ:

нисходящие , структурное и модульное программирование .

        Идея нисходящего проектирования заключается в том, что программа разбивается на более мелкие элементы, которые, в свою очередь, могут быть разбиты на более простые и т.д. до тех пор, пока они не будут доведены до таких примитивов, которые могут быть реализованы на ЭВМ. Этот метод является незаменимым при разработки сложных по характеру и больших по объему программ.

     Реализация метода нисходящего  проектирования тесно связана  с другим понятием программирования  – модульным проектированием.

      Модуль-это последовательность логически  связанных фрагментов, оформленных  как отдельная часть программы. (2)

      При разработки программного  модуля целесообразно придерживаться следующего порядка:

• Изучение и проверка спецификации модуля, выбор языка программирования;
• выбор алгоритма и структуры данных;
• программирование (кодирование) модуля;
• шлифовка текста модуля;
• проверка модуля;
• компиляция модуля.

      Первый шаг разработки программного модуля в значительной степени представляет собой смежный контроль структуры программы снизу. В завершении этого шага выбирается язык программирования.

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

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

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

     Шаг проверки модуля представляет собой ручную проверку внутренней логики модуля до начала его отладки.

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

При программировании модуля следует иметь в виду, что  программа должна быть понятной не только компьютеру, но и человеку.

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

       Одной из целей структурного программирования  было значительно облегчить процесс разработки и отладки программных модулей, а главное – процесс их понимания для сопровождения и модификации. Основная особенность структурного программирования заключается в отказе от оператора безусловного перехода (оператор GOTO). Этот оператор позволяет из любого места программы в процессе ее выполнения перейти в любое другое место за исключением некоторых специфических случаев.      Любую программу можно создать с использованием трех алгоритмических структур: линейной, циклической и ветвящейся. Отказ от этого оператора позволяет читать программу сверху вниз без перерывов и возвратов, возникающих из-за передачи управления. С другой стороны применения оператора перехода упрощает процесс написания программы. В настоящее время в структурном программировании допускается использование оператора перехода, но при условиях, чтобы количество этих операторов в программе было минимальным, а передача управления осуществлялась только вниз по программе.(2)

 

2. Жизненный цикл программного средства.

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

        В настоящее время можно выделить 5 основных подходов к организации  процесса создания и использования  ПС.

• Водопадный подход. При таком подходе разработка ПС состоит из цепочки этапов. На каждом этапе создаются документы, используемые на последующем этапе. В исходном документе фиксируются требования к ПС. В конце этой цепочки создаются программы, включаемые в ПС.
• Исследовательское программирование. Этот подход предполагает быструю реализацию рабочих версий программ ПС, выполняющих лишь в первом приближении требуемые функции. После экспериментального применения реализованных программ производиться их модификация с целью сделать их более полезными для пользователей. Этот процесс повторяется до тех пор, пока ПС не будет достаточно приемлемо для пользователей.
• Формальные преобразования. Этот подход включает разработку формальных спецификаций ПС и превращение их программы путем корректных преобразований.
• Сборочное программирование. Этот подход предполагает, что ПС конструируется, главным образом, из компонент, которые уже существуют.

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

 
 
 

 Стадия производства

      программных изделий

  Стадия разработки ПС

                                                                         Стадия эксплуатации ПС

                                                                        Фаза применения ПС

                                                                          Фаза сопровождения ПС

Этап внешнего

описания  ПС

Этап аттестации

                         ПС

    Этап конструирования ПС                                         Этап кодирования

                                                                                                           ПС

           Рис.1. Стадии фазы жизненного цикла ПС.

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

 

4.Понятие качества и надежности программного средства.

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

        Качество ПС - это совокупность его черт и характеристик, которые влияют на его способность удовлетворять заданные потребности пользователей. В настоящее время критериями качества

ПС принято  считать:

• функциональность,
• надежность,
• легкость применения,
• эффективность,
• сопровождаемость,
• мобильность.