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

Список пользователей

Список пользователей — это один из инструментов администрирования.

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

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

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

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

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

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

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

Источник

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

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

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

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

Все программы по характеру использования и категориям пользователей можно разделить на два класса:

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

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

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

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

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

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

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

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

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

Источник

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

Предмет: Технология разработки программных продуктов.

Тема: Документирование программных средств.

Ознакомление с видами документов при разработки ПО.

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

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

— Основы алгоритмизации и программирования

Оборудование: доска, мел, письменные принадлежности, проектор, ПК

Тип урока: комбинированный

Метод обучения: Объяснительно иллюстративный

— Проверка готовности кабинета

2. Постановка цели урока

3.Повторение пройденного материала

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

Инструментальные системы технологии программирования

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

4.Сообщение новых знаний

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

2. Пояснительная записка

3. Руководство пользователя

4. Руководство системного программиста

5. Основные правила оформления программной документации

5. Восприятие и осознание учащимися нового материала

6. Осмысление обобщение и систематизация знаний

7. Подведение итогов урока и постановка домашнего задания

Выучить содержимое темы

Гагарина Л.Г. стр. С.233-238.

Ответить на вопросы:

Лекция №11:Составление программной документации

6. Виды программных документов

7. Пояснительная записка

8. Руководство пользователя

9. Руководство системного программиста

10. Основные правила оформления программной документации

11. Правила оформления расчетно-пояснительных записок при курсовом проектировании

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

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

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

К программным относят документы, содержащие сведения, необходи­мые для разработки, сопровождения и эксплуатации программного обеспе­чения. Документирование программного обеспечения осуществляется в со­ответствии с Единой системой программной документации (ГОСТ 19.ХХХ). Так ГОСТ 19.101-77 устанавливает виды программных документов для про­граммного обеспечения различных типов. Ниже перечислены основные про­граммные документы по этому стандарту и указано, какую информацию они должны содержать.

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

Допускается объединять отдельные виды эксплуатационных докумен­тов, кроме формуляра и ведомости. Необходимость объединения указывает­ся в техническом задании, а имя берут у одного из объединяемых документов. Например, в настоящее время часто используется эксплуатационный до­кумент, в который отчасти входит руководство системного программиста, программиста и оператора. Он называется «Руководство пользователя» (см §3).

Рассмотрим наиболее важные программные документы более подробно.

2. Пояснительная записка

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

Содержание пояснительной записки по стандарту (ГОСТ 19.404-79) должно выглядеть следующим образом:

• назначение и область применения;

• ожидаемые технико-экономические показатели;

• источники, используемые при разработке.

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

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

Раздел Технические характеристики должен содержать следующие под­разделы:

• постановка задачи, описание применяемых математических методов и допущений и ограничений, связанных с выбранным математическим аппара­том;

• описание алгоритмов и функционирования программы с обосновани­ем принятых решений;

• описание и обоснование выбора способа организации входных и вы­ходных данных;

• описание и обоснование выбора состава технических и программных средств на основании проведенных расчетов или анализов.

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

В разделе Источники, использованные при разработке, указывают пере­чень научно-технических публикаций, нормативно-технических документов и других научно-технических материалов, на которые есть ссылки в исход­ном тексте.

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

3. Руководство пользователя

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

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

• излагайте ясно, используйте короткие предложения;

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

Руководство пользователя, как правило, содержит следующие разделы:

• общие сведения о программном продукте;

• инструкции по работе (или описание пользовательского интерфейса);

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

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

В разделе Запуск, как правило, описаны действия по запуску программ­ного продукта и сообщений, которые при этом могут быть получены.

Раздел Инструкции по работе обычно содержит описание режимов ра­боты, форматов ввода-вывода информации и возможных настроек.

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

4. Руководство системного программиста

По ГОСТ 19.503-79 руководство системного программиста должно со­держать всю информацию, необходимую для установки программного обес­печения, его настройки и проверки работоспособности. Кроме того, как ука­зывалось выше, в него часто включают и описание необходимого обслужи­вания, которое раньше приводилось в руководстве оператора (ГОСТ 19.505-79) и/или руководстве по техническому обслуживанию (ГОСТ 19.508-79). В настоящее время данную схему используют для составления руководства системному администратору.

Руководство системного программиста должно содержать следующие разделы:

• общие сведения о программном продукте,

• сообщения системному программисту.

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

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

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

В разделе Проверка программы должно быть приведено описание спо­собов проверки работоспособности программы, например контрольные при­меры.

В разделе Дополнительные возможности должно быть приведено опи­сание дополнительных возможностей программы и способов доступа к ним.

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

5. Основные правила оформления программной документации

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

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

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

Разделы и подразделы нумеруются арабскими цифрами с точкой. Разде­лы должны иметь порядковые номера 1, 2, и т. д. Номер подраздела включа­ет номер раздела и порядковый номер подраздела, входящего в данный раз­дел, разделенные точкой. Например: 2.1, 3.5. Ссылки на пункты, разделы и подразделы указывают, используя порядковый номер раздела или пункта, на­пример, «в разд. 4», «в п. 3.3.4».

Текст разделов печатают через 1,5-2 интервала. При использовании тек­стовых редакторов высота букв и цифр должна быть не менее 1,8 мм (шриф­ты № 11-12).

Рис.12. Форма окна основного меню

На все рисунки, таблицы и формулы в записке должны быть ссылки в виде: «(рис. 12)» или «форма окна основного меню приведена на рис. 12».

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

Если рисунок занимает более одной страницы, на всех страницах, кроме первой, проставляется номер рисунка и слово «Продолжение». Например:

Рис. 12. Продолжение

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

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

Ссылки на таблицы в тексте пояснительной записки указывают в виде слова «табл.» и номера таблицы. Например:

Результаты тестов приведены в табл. 4.

Номер формулы ставится с правой стороны страницы в круглых скобках на уровне формулы. Например:

z := sin ( x )+ ln ( y ); (12)

Ссылка на номер формулы дается в скобках. Например: «расчет значе­ний проводится по формуле (12)».

Оформление приложений. Каждое приложение должно начинаться с новой страницы с указанием в правом углу слова «ПРИЛОЖЕНИЕ» пропис­ными буквами и иметь тематический заголовок. При наличии более одного приложения все они нумеруются арабскими цифрами: ПРИЛОЖЕНИЕ 1, ПРИЛОЖЕНИЕ 2 и т. д. Например:

ПРИЛОЖЕНИЕ 2 Титульный лист расчетно-пояснительной записки

Рисунки и таблицы, помещаемые в приложении, нумеруют арабскими цифрами в пределах каждого приложения с добавлением буквы «П», Напри­мер:

Если в приложении приводится текст программы, то каждый файл оформляют как рисунок с наименованием файла и его назначением, напри­мер:

Оформление списка литературы.

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

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

ли она есть), год выпуска, том (если есть), номер издания (журнала) и номе­ра страниц, на которых помещена статья.

При ссылке на источник из списка литературы (особенно при обзоре аналогов) надо указывать порядковый номер по списку литературы, заклю­ченный в квадратные скобки; например: [5].

Лекция 13. ДОКУМЕНТИРОВАНИЕ ПРОГРАММНЫХ СРЕДСТВ

13.1. Документация, создаваемая в процессе разработки программных средств.

При разработке ПС создается большой объем разнообразной документации. Она необходима как средство передачи информации между разработчиками ПС, как средство управления разработкой ПС и как средство передачи пользователям информации, необходимой для применения и сопровождения ПС. На создание этой документации приходится большая доля стоимости ПС.

Эту документацию можно разбить на две группы [13.1]:

Документы управления разработкой ПС.

Документы, входящие в состав ПС.

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

Пользовательская документация ПС (П-документация).

Документация по сопровождению ПС (С-документация).

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

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

В связи с этим следует различать две категории пользователей ПС: ординарных пользователей ПС и администраторов ПС. Ординарный пользователь ПС (end-user) использует ПС для решения своих задач (в своей предметной области). Это может быть инженер, проектирующий техническое устройство, или кассир, продающий железнодорожные билеты с помощью ПС. Он может и не знать многих деталей работы компьютера или принципов программирования. Администратор ПС (system administrator) управляет использованием ПС ординарными пользователями и осуществляет сопровождение ПС, не связанное с модификацией программ. Например, он может регулировать права доступа к ПС между ординарными пользователями, поддерживать связь с поставщиками ПС или выполнять определенные действия, чтобы поддерживать ПС в рабочем состоянии, если оно включено как часть в другую систему.

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

В соответствии с работами [13.1, 13.2] можно считать типичным следующий состав пользовательской документации для достаточно больших ПС:

13.3. Документация по сопровождению программных средств.

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

(1) документация, определяющая строение программ и структур данных ПС и технологию их разработки;

(2) документацию, помогающую вносить изменения в ПС.

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

Внешнее описание ПС ( Requirements document ).

Описание архитектуры ПС ( description of the system architecture ), включая внешнюю спецификацию каждой ее программы.

Тексты модулей на выбранном языке программирования (program source code listings).

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

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

Документация второй группы содержит

Руководство по сопровождению ПС (system maintenance guide), которое описывает известные проблемы вместе с ПС, описывает, какие части системы являются аппаратно- и программно-зависимыми, и как развитие ПС принято в расчет в его строении (конструкции).

Литература к лекции 13.

13.2. ANSI/IEEE Std 1063-1988, IEEE Standard for Software User Documentation.

13.3. ANSI/IEEE Std 830-1984, IEEE Guide for Software Requirements Specification.

13.4. ANSI/IEEE Std 1016-1987, IEEE Recommended Practice for Software Design Description.

13.5. ANSI/IEEE Std 1008-1987, IEEE Standard for Software Unit Testing.

13.6. ANSI/IEEE Std 1012-1986, IEEE Standard for Software Verification and Validation Plans.

13.7. ANSI/IEEE Std 983-1986, IEEE Guide for Software Quality Assurance Planning.

13.8. ANSI/IEEE Std 829-1983, IEEE Standard for Software Test Documentation.

Источник