Программное обеспечение: понятия и цели

Размещено на http://www.allbest.ru/

Содержание

Программное обеспечение как изделие

Постановка целей

Документ «Соглашение о требованиях»

Документ «Постановка задачи»

Литература

Программное обеспечение как изделие

Современные программы решают самые различные задачи по содержанию и отраслевому значению.

В НИИ и в ВУЗах во многих случаях программы создаются в единственном экземпляре для решения частных исследовательских задач, для ускорения вычислений, моделирования процессов, обработки экспериментального материала и т.д. Такие программы не имеют массового применения и доступны для использования только тем, кто их разработал. Они становятся объектами научно-технического творчества и редко становятся промышленными изделиями.

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

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

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

В этом случае речь идет о программном изделии (о программном продукте для ЭВМ).

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

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

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

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

- разработчик создает программное обеспечение для себя или, по крайней мере, организационно связан с пользователями разрабатываемого программного обеспечении;

- пользователь формулирует свои требования непосредственно разработчику, если последний сам не является одновременно пользователем;

- пользователь активно участвует в разработке или в обслуживании программного обеспечения;

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

- разработчик сам вводит в действие программное обеспечение у пользователя;

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

- программы не имеют массового применения и доступны для использования только тем, кто их разработал;

- использование программы прекращается после получения результата.

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

- разработчик не знаком с пользователем;

- требования пользователя формируются либо разработчиком, либо передаются ему посреднической организацией (например, поставляющей программное обеспечение);

- пользователи не участвуют в рассмотрении и согласовании проектных решений, если не считать редких случаев, когда их интересы представлены посредниками;

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

- пользователи вводят программное обеспечение в действие либо сами, либо с посторонней помощью, но эта помощь исходит не от разработчика;

- проблемы, возникшие при использовании программного обеспечения, разрешаются путем переписки, а иногда через посредника;

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

- программное обеспечение используется многократно и длительное время.

Постановка целей

Цели - это конкретные ориентиры для программного продукта. Процесс их постановки - это, прежде всего, процесс принятия компромиссных решений.

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

В целом цели программного обеспечения можно разбить на 9 больших групп.

Надежность - мера работы программного обеспечения без отказов в течение определенного периода времени.

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

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

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

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

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

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

Удобство сопровождения - это мера затрат времени и средств на исправление ошибки в работающем программном изделии.

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

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

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

Документация -- это вопрос качества и количества публикаций для пользователя.

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

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

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

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

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

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

- цели продукта, т.е. окончательного результата с точки зрения пользователя

- и цели проекта, такие, как график, стоимость, степень тестирования и т.д.

Цели продукта:

1. Резюме. Вначале следует коротко сформулировать общее назначение ПО.

2. Определение пользователя. Если разрабатывается большое ПО с разными группами пользователей, они должны быть определены.

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

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

5. Эффективность - цели производительности, такие, как временные характеристики, пропускная способность, использование ресурсов. Также необходимые средства измерения произ­водительности и средства настройки.

6. Совместимость программного изделия с другим. Указываются также относящиеся к делу международные и государственные стандарты.

7. Конфигурация аппаратуры и ПО, в которых система может работать и другие программные продукты, от которых она зависит.

8. Безопасность данных от несанкционированного доступа.

9. Обслуживание.

10. Установка-- методы и средства настройки программного изделия на конкретные условия эксплуатации.

11. Надежность.

Цели проекта:

1. Ориентировочная стоимость каждого проекта.

2. Календарный план проекта.

3. Цели для каждого процесса тестирования.

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

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

6. Уровни надежности на каждом этапе разработки для достижения заданной надежности продукта.

7. Внутренняя документация при работе над проектом.

8. Критерии для готовности готового продукта к использованию.

При постановке целей распространены следующие ошибки:

- цели не формулируются явно;

- составляется беглый набросок списка целей, причем жизненно важные цели в него не включаются;

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

- цели формулируются только для продукта. Забывается формулировка целей для проекта.

Документ «Соглашение о требованиях»

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

-- соглашение о требованиях;

-- техническое задание;

-- технические требования;

-- постановка задачи.

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

Документ «Соглашение о требованиях» является основным средством управления разработкой программного обеспечения или генеральным планом его разработки.

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

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

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

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

Следует напомнить, что пользователь несет ответственность за проверку требований на полноту и точность, а разработчик - за проверку их на осуществимость и понятность.

Документ «Постановка задачи»

В организациях, специализирующихся на разработке программного обеспечения, в результате системного анализа формируется документ «Соглашение о требованиях» («Техническое задание»).

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

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

Документ «Постановка задачи» может содержать разделы:

1. Заголовок к программе.

2. Условие задачи. Формулируется условие задачи, краткое описание разрабатываемой программы и ее назначение.

3. Начало/окончание работы. Указывается месяц и год начала/окончания разработки программного продукта.

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

5. Краткая характеристика объекта. Описывается объект разработки. Как решается задача без компьютера. Какая часть ручной работы будет заменена программой и т.д.

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

7. Цель и назначение программы.

8. Основные требования. Перечисляются требования пользователя к разрабатываемому программному продукту. Здесь же с точки зрения пользователя следует перечислить функции прог­раммного продукта.

9. Входная информация. Описываются все входные данные программного обеспечения с точки зрения их содержания и назначения -- отчеты, файлы, записи, поля данных, таблицы. Их возможные носители и средства отображения информации и т.д.

10. Выходная информация. Описываются выходные данные так же, как в пункте 9.

11. Требования к аппаратному и программному обеспечению. Конфигурация аппаратуры и программного обеспечения, в которых разрабатываемая система может работать и другие прог­раммные продукты, от которых она зависит.

12. Внешние ограничения.

13. Эффективность. Цели производительности, такие, как временные характеристики, пропускная способность, использование ресурсов, а также необходимые средства измерения производительности и средства настройки.

14. Безопасность данных от несанкционированного доступа.

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

16. Мобильность. Описываются требования и цели обеспечения переноса программного продукта из одних рабочих условий в другие.

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

18. Другие соглашения сторон.

19. Терминология. Четко определяется вся терминология, которая может оказаться специфической для данной разработки.

Литература

1. Предметно-ориентированное проектирование (DDD). Структуризация сложных программных систем. Эрик Эванс. Изд. Вильямс, 2010, стр.444

2. Профессиональная разработка программного обеспечения. Стив Макконнелл. Изд. Символ-Плюс,2007, стр.240

3. Разработка и стандартизация программных средств. А. Ю. Крупский, Л. А. Феоктистова. Изд. Дашков и Ко, 2008, стр.100

Размещено на Allbest.ru