Как сделать описание программного продукта

Обновлено: 05.07.2024

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

Рубрика	Программирование, компьютеры и кибернетика
Вид	курсовая работа
Язык	русский
Дата добавления	05.04.2009
Размер файла	46,8 K

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

2. Теоретическая часть

2.1. Разработка программных продуктов

2.1.1. Эффективность и оптимизация программ

2.1.2. Обеспечение качества программного продукта

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

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

4.1. Требования к функциональным характеристикам

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

4.1.2. Организация входных и выходных данных

4.2. Требования к надёжности

4.2.1. Предусмотреть контроль вводимой информации

4.3. Требования к составу и параметрам технических средств

4.4. Требования к программной совместимости

5.1. Исходные данные и результат работы программы

5.1.1. Исходный файл

5.1.2. Результирующий файл

5.2. Блок-схемы индивидуальной части курсовой работы

2. ТЕОРЕТИЧЕСКАЯ ЧАСТЬ

2.1. Разработка программных продуктов

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

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

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

Предварительный внешний проект - определение взаимодействий с пользователем, но без рассмотрения деталей (формат ввода/вывода).

Детальный внешний проект - завершение определения взаимодействий с пользователем, описание всех потребностей ввода/вывода.

Архитектура системы - разложение системы на множество программ и определение сопряжения между ними.

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

Внешний проект модуля - определение всех сопряжении модуля.

Проект логики модуля - разработка логики модуля, результат - текст модуля.

2.1.1. Эффективность и оптимизация программ

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

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

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

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

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

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

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

2.1.2. Обеспечение качества программного продукта

Разработка программного обеспечения - это, прежде всего, нахождение способов получения качественного программного продукта. Что мы подразумеваем, когда мы говорим о "качестве" программного обеспечения? Качество программного обеспечения может измеряться во внешних характеристиках (например, легкий в использовании, выполняется быстро) или во внутренних характеристиках (например, модульная конструкция, читабельный код).

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

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

- функциональность

- надежность

- легкость применения

- эффективность

- сопровождаемость

- мобильность

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

Надежность подробно обсуждалась в первой лекции.

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

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

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

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

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

3. НАЗНАЧЕНИЕ И ОБЛАСТЬ ПРИМЕНЕНИЯ

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

4. ТРЕБОВАНИЕ К ПРОГРАММНОМУ ПРОДУКТУ

4.1. Требования к функциональным характеристикам

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

- вывод шапки таблицы (SH);

- вывод данных одной записи (P);

- создание файла (SOZ);

- дополнение файла новыми записями ();

- запись данных в файл (ZF);

- чтение данных из файла (CHT);

- модификация ряда записей файла ();

- отсортировать таблицу по возрастанию ();

- удаление записей из типизированного файла ();

- функция для фильтрации строки - удаления пробелов (FILTR).

4.1.2. Организация входных и выходных данных:

- Выходные данные поступают в текстовый файл “REZYL.txt”;

4.2. Требования к надёжности

4.2.1. Предусмотреть контроль вводимой информации

Нет контроля вводимой информации.

4.3. Требования к составу и параметрам технических средств:

Система должна работать на IBM - совместимых персональных компьютерах.

тип процессора Pentium и выше

объём оперативного запоминающего устройства 32 Мб и более

объём свободного места на жёстком диске.40 Мб

тип процессора Pentium II и выше

объём оперативного запоминающего устройства 128 Мб и более

объём свободного места на жёстком диске 60 Мб

4.4. Требования к программной совместимости

Программа должна работать под управлением семейства операционных систем Win 32 (Windows 95/98/2000/ME/XP и т.п.) и ОС MS DOS версии не ниже 5.5. Базовый язык программирования - Turbo Pascal 7.0.

5. ПРОГРАММНАЯ ДОКУМЕНТАЦИЯ МОДУЛЯ

5.1. Исходные данные и результат работы программы

| Ivanov I.I. | 1000.00 | 100.53 | 166.50 | 9004.50 |

| Petrov P.P. | 2000.00 | 200.62 | 167.50 | 1864.40 |

| Repina G.G. | 3000.00 | 300.43 | 164.50 | 3150.50 |

| Sidirov F.F. | 4000.00 | 400.44 | 148.10 | 4256.50 |

| Kotov K.K. | 1512.00 | 500.67 | 168.40 | 1864.50 |

| Somova S.S. | 2654.00 | 600.69 | 168.10 | 3264.40 |

| Dedov D.D. | 1655.00 | 700.56 | 684.10 | 1680.40 |

| Popova P.P. | 3545.00 | 800.85 | 165.40 | 4210.60 |

| Sidova S.S. | 1658.00 | 900.75 | 168.10 | 2566.10 |

| Komov K.K. | 6574.00 | 1000.95 | 642.10 | 7000.60 |

Ivanov I.I. 1000.0 100.53 166.5 9004.5

Petrov P.P. 2000.0 200.62 167.5 1864.4

Repina G.G. 3000.0 300.43 164.5 3150.5

Sidirov F.F. 4000.0 400.44 148.1 4256.5

Kotov K.K. 1512.0 500.67 168.4 1864.5

Somova S.S. 2654.0 600.69 168.1 3264.4

Dedov D.D. 1655.0 700.56 684.1 1680.4

Popova P.P. 3545.0 800.85 165.4 4210.6

Sidova S.S. 1658.0 900.75 168.1 2566.1

Komov K.K. 6574.0 1000.95 642.1 7000.6

5.1.2. Результирующий Файл:

a) Ведомость зарплаты:

| Ivanov I.I. | 1000.00 | 100.53 | 166.50 | 9004.50 |

| Petrov P.P. | 2000.00 | 200.62 | 167.50 | 1864.40 |

| Repina G.G. | 3000.00 | 300.43 | 164.50 | 3150.50 |

| Sidirov F.F. | 4000.00 | 400.44 | 148.10 | 4256.50 |

| Kotov K.K. | 1512.00 | 500.67 | 168.40 | 1864.50 |

| Somova S.S. | 2654.00 | 600.69 | 168.10 | 3264.40 |

| Dedov D.D. | 1655.00 | 700.56 | 684.10 | 1680.40 |

| Popova P.P. | 3545.00 | 800.85 | 165.40 | 4210.60 |

| Sidova S.S. | 1658.00 | 900.75 | 168.10 | 2566.10 |

| Komov K.K. | 6574.00 | 1000.95 | 642.10 | 7000.60 |

b) Нахождение среднего размера оклада:

| Ivanov I.I. | 1000.00 | 100.53 | 166.50 | 9004.50 |

| Petrov P.P. | 2000.00 | 200.62 | 167.50 | 1864.40 |

| Repina G.G. | 3000.00 | 300.43 | 164.50 | 3150.50 |

| Sidirov F.F. | 4000.00 | 400.44 | 148.10 | 4256.50 |

| Kotov K.K. | 1512.00 | 500.67 | 168.40 | 1864.50 |

| Somova S.S. | 2654.00 | 600.69 | 168.10 | 3264.40 |

| Dedov D.D. | 1655.00 | 700.56 | 684.10 | 1680.40 |

| Popova P.P. | 3545.00 | 800.85 | 165.40 | 4210.60 |

| Sidova S.S. | 1658.00 | 900.75 | 168.10 | 2566.10 |

| Komov K.K. | 6574.00 | 1000.95 | 642.10 | 7000.60 |

Sredniy razmer oklada 5519.60

c) Сведенья о сотрудниках с окладом менее 3000 рублей

Svedenia o sotrudnikah s okladom menshe 3000 rub:

| Ivanov I.I. | 1000.00 | 100.53 | 166.50 | 9004.50 |

| Petrov P.P. | 2000.00 | 200.62 | 167.50 | 1864.40 |

| Kotov K.K. | 1512.00 | 500.67 | 168.40 | 1864.50 |

| Somova S.S. | 2654.00 | 600.69 | 168.10 | 3264.40 |

| Dedov D.D. | 1655.00 | 700.56 | 684.10 | 1680.40 |

| Sidova S.S. | 1658.00 | 900.75 | 168.10 | 2566.10 |

d) Сведенья о сотрудниках с премией больше 1000 рублей

Svedenia o sotrudnikah s premiey bolshe 1000 rub:

| Komov K.K. | 6574.00 | 1000.95 | 642.10 | 7000.60 |

e) Суммарная сумма премий всех сотрудников

| Ivanov I.I. | 1000.00 | 100.53 | 166.50 | 9004.50 |

| Petrov P.P. | 2000.00 | 200.62 | 167.50 | 1864.40 |

| Repina G.G. | 3000.00 | 300.43 | 164.50 | 3150.50 |

| Sidirov F.F. | 4000.00 | 400.44 | 148.10 | 4256.50 |

| Kotov K.K. | 1512.00 | 500.67 | 168.40 | 1864.50 |

| Somova S.S. | 2654.00 | 600.69 | 168.10 | 3264.40 |

| Dedov D.D. | 1655.00 | 700.56 | 684.10 | 1680.40 |

| Popova P.P. | 3545.00 | 800.85 | 165.40 | 4210.60 |

| Sidova S.S. | 1658.00 | 900.75 | 168.10 | 2566.10 |

| Komov K.K. | 6574.00 | 1000.95 | 642.10 | 7000.60 |

Summa premiy 5506.49

f) Поиск записей файла по сочетанию двух заданных поисковых признаков с помощью “ppoi.dat”:

Нахождение в ведомости зарплаты людей с ФИО Sidova S.S. и окладом 1658.00.

Naiti v baze svedenia lud9h s fio = Sidova S.S. i okladom 1658.00

| Sidova S.S. | 1658.00 | 900.75 | 168.10 | 2566.10 |

5.2. Блок-схемы индивидуальной части курсовой работы

Блок-схема процедуры а

Блок-схема процедуры c1

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

Чтобы описать программу, начните с общего вступления. Опишите основную проблему, с которой сталкивается пользователь. Естественно, это должна быть та самая проблема, которую и решает описываемая программа. Кстати это хороший способ сразу же очертить целевую аудиторию пользователей. Те, кому она будет полезна и необходима, ее скачают или купят. Другие же пользователи сэкономят время и не станут далее читать. Также во вступлении кратко опишите основные возможности программы. Для этого достаточно 1-2 предложений.

Укажите системные требования к компьютерному оборудованию. Чтобы наиболее полно описать программу, сделайте градацию. Распишите минимальные требования и требования для комфортной работы.

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

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

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

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

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

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

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

В одной статье невозможно описать даже малую часть имеющихся на данный момент ИТ инструментов и методов. Рассмотрим общие типовые подходы к разработке и внедрению автоматизированной системы.

Независимо от масштаба проекта автоматизации бизнес-процесса или разработки "продающего" (обслуживающего) сайта, цикл разработки ПО условно можно разделить на четыре фазы:

разработка функциональных требований к ПО (технического задания) [аналитик];
разработка архитектуры системы [инженер-архитектор]

разработка структуры базы данных (далее - БД) [программист] ;
кодирование: разработка программной логики, функций, интерфейса [программист];
интеграция с другими информационными системами (при необходимости) [программист]

разработка сценариев тестирования [программист/тестировщик];
разработка автотестов [QA программист];
функциональное (ручное) тестирование [тестировщик];
разработка технической документации [программист];
разработка пользовательской документации [технический писатель]

внедрение, обучение пользователей, сбор замечаний и ошибок [аналитик-консультант];
техническая поддержка (сбор замечаний, исправление ошибок, консультирование пользователей) [специалист]

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

Главным условием является необходимость документирования всех собранных требований и их согласование с Заказчиком.

Карл Вигерс в книге "Разработка требований к программному обеспечению" выделил следующие требования:

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

Требования пользователей (user requirements) описывают цели и задачи, которые пользователям позволит решить система.

Функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Функциональные требования документируются в спецификации требований к ПО (software requirements specification, SRS), где описывается так полно, как необходимо, ожидаемое поведение системы.

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

Основными проблемами данного этапа являются:

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

1) разработка в соответствии с ГОСТами серии 19 и 34. ГОСТы предоставляют четкую структуру разрабатываемой документации, обладают свойствами полноты и непротиворечивости, а также снимают спорные вопросы между исполнителем и заказчиком к результатам работ.

Ограничения:
- сложность разработки, согласования и дальнейшей поддержки
- жесткие требования к детализации

2) пользовательские истории (англ. User Story) — способ описания требований к разрабатываемой системе, сформулированных как одно или более предложений на повседневном языке пользователя. Применяется в Scrum методологии как быстрый способ документирования требований клиента, без необходимости разрабатывать обширные формализованные документы и впоследствии тратить ресурсы на их поддержание.

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

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

4) прецедент (англ. Use Case) - спецификация последовательностей действий (варианты последовательностей и ошибочные последовательности) в Унифицированном языке моделирования (UML), которые может осуществлять система, подсистема или класс, взаимодействуя с внешними действующими лицами (англ. Actors).

5) спецификация требований программного обеспечения (англ. Software Requirements Specification, SRS) является полным описанием поведения системы, которая будет создана, а также нефункциональные требования в виде дополнительных ограничений (требования к эффективности, безопасности и др.).

6) дизайн продукта - разработка пользовательских интерфейсов. Выделяют UX и UI дизайны. Простыми словами: UX делает интерфейсы полезными, а UI делает интерфейсы красивыми.

Джастин Мифсуд, основатель блога об юзабилити, дает такое определение: "User Experience дизайн — многогранная концепция, которая включает множество дисциплин: интерактивный дизайн, информационную архитектуру, визуальный дизайн, юзабилити и взаимодействие между человеком и компьютером."

По словам дизайнера Ника Бабича: " UX дизайнер, скорее будет разрабатывать потоки пользователей, шаги, которые пользователь предпримет, чтобы, например, подписаться на рассылку. Каким шагам они будут следовать и как они поймут, что всё удалось? Затем проект переходит UI дизайнеру. UI дизайнер усовершенствует эти взаимодействия добавляя цвет и подчеркивая оригинальный дизайн, давая им подсказки, и показывая направление к новостной рассылке."

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

Процесс разработки разделяют на back-end и front-end.

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

создание HTML-страницы сайта на основе дизайн-макетов;
вёрстка сайта и шаблонов для CMS;
привязка к пользовательскому интерфейсу скриптов, которые обеспечивают визуализацию и анимацию страниц сайта;
обеспечение необходимого уровня пользовательского интерфейса (UI — User Interface) и опыта взаимодействия (UX — Uzer Experience).

При совместной работе разработчики применяют систему контроля версий и принцип разработки ветвями.

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

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

Часто требуется интегрировать несколько программных продуктов между собой для получения эффекта синергии.

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

Различают следующие виды интеграции:

1) консолидация - данные извлекаются из источников, и помещаются в Хранилище данных. Процесс заполнения Хранилища состоит из трех фаз — извлечение, преобразование, загрузка (Extract, Transformation, Loading — ETL). Еще одна распространенная технология консолидации данных — управление содержанием корпорации (enterprise content management, сокр. ECM). Большинство решений ECM направлены на консолидацию и управление неструктурированными данными, такими как документы, отчеты и web-страницы.
Консолидация — однонаправленный процесс, то есть данные из нескольких источников сливаются в Хранилище, но не распространяются из него обратно в распределенную систему. Часто консолидированные данные служат основой для приложений бизнес-аналитики (Business Intelligence, BI), OLAP-приложений.

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

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

4) сервисно-ориентированная архитектура SOA (Service Oriented Architecture): данные также остаются у владельцев. При запросе происходит обращение к определённым сервисам, которые связаны с источниками, где находится информация и её конкретный адрес.

5) быстрая и простая форма интеграции является применение интерфейса прикладного программирования (Application Programming Interface, API). API позволяет абстрагироваться от того, как именно эта функциональность реализована.

Разработанный функционал обязательно должен проходить стадию тестирования - проверки соответствия между реальным и ожидаемым поведением программы. По сути, это проверка качества продукта (Quality Assurance - QA): готов ли продукт к выпуску, соответствует ли требованиям и уровню качества.

Методология тестирования включает работы по планированию (Test Management), проектированию тестов (Test Design), выполнению тестирования (Test Execution) и анализу полученных результатов (Test Analysis).

После проведения доработок (bag fix) должно быть проведено повторное тестирование (регрессионное, а также санитарное тестирование и тестирование согласованности/исправленности) для проверки, что дефект/проблема действительно решена.

Выделяют следующие виды тестирования:

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

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

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

Тестирование удобства пользования (usability testing) - установление степени удобства использования, обучаемости и понятности, привлекательности для пользователей. Проводят оценку производительности/эффективности, правильности, эмоциональной реакции.

При проектировании тестирования разработывается план тестирования и набор кейсов.

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

Методология представлена в стандартах RUP и IEEE829.

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

Рекомендую применять встроенные функции WiKi в Redmine/JIRA или систему CMS (см. статью).

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

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

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

Для эффективного внедрения рекомендую разработать Памятки (на одном листе А4) и/или Стандартную работу для пользователей, в которых кратко описываются действия разных категорий пользователей.

В процессе эксплуатации могут возникать ошибки в программном обеспечении, а также пожелания по улучшениям (доработкам) у пользователей. Любое обращение от пользователей должно быть зафиксировано в системе Service Desk (например, OTRS, Freshservice и т.п.).

Лучшие практики организации ИТ услуг закреплены в библиотеках ITIL (IT Service Management - ориентирован на технологиях) и ITSM (IT Systems Management - ориентирован на услугах). Эти стандарты предлагают построение процессной модели для управления ИТ- подразделением, результатом деятельности которого являются ИТ- услуги для бизнеса с прозрачной стоимостью, качество которых гарантируется путем организации непрерывного контроля. ITSM рекомендует сосредоточиться на клиенте и его потребностях, на ИТ-услугах, предоставляемых пользователю информационными технологиями, а не на них самих. При этом процессная организация предоставления услуг и наличие заранее оговоренных уровней параметров эффективности позволяет ИТ-службе предоставлять качественные ИТ-услуги, измерять и улучшать их качество.

Все услуги и их параметры фиксируются в Соглашениях об уровне услуг (SLA). В SLA содержится детальное описание предоставляемого сервиса, в том числе перечень параметров качества, методов и средств их контроля, времени отклика поставщика на запрос от потребителя, а также штрафные санкции за нарушение этого соглашения. Для соблюдения условий SLA поставщик услуг заключает операционное соглашение об уровне услуг (OLA, operational-level agreement) с другими внутренними подразделениями, от которых зависит качество предоставления услуг.

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

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

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

Что такое руководство пользователя и для чего его создавать

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

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

Общие советы по созданию пользовательской документации

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

После этого важно подумать о том:

Где пользователь будет к нему обращаться: дома, на работе, в машине?
Как часто он будет его просматривать?
Насколько объективно сложен для понимания продукт?

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

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

Структура руководства пользователя

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

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

Для чего создан продукт.
Какие задачи он решает.
Какие основные выгоды от использования для клиента.

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

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

Ни одно руководство не обойдется без таких разделов как: "Частые вопросы" и "Устранение типовых проблем" В них разбираются вопросы и проблемы, с которыми часто сталкиваются пользователи. Для заполнения данного раздела вам скорее всего понадобятся уже готовые отзывы клиентов. Если у вас абсолютно новый продукт, вы можете предугадать проблемы ваших клиентов либо на первое время не включать данный пункт в ваше руководство.

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

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

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

Удобной особенностью инструмента является возможность экспортировать один и тот же документ в форматы: HTML, CHM, PDF. Простой и понятный интерфейс практически сам подскажет как быстро просмотреть документ в различных форматах и настроить его под вывод в эти форматы.

Любой проект в Dr.Explain вы можете создать с нуля или импортировать уже существующую документацию, например из формата MS Word, HTML или CHM-файла, и буквально за несколько минут создать из нее онлайн-помощь, файл справки в формате CHM, или документ в формате PDF.

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

У программы свой собственный редактор, оптимизированный под работу со сложной документацией. Основные функции редактора вынесены в компактный тулбар. Это - управление стилем текста, форматирование абзацев, вставка ссылок, изображений, видео, таблиц и списков, а также вставка специальных объектов. Dr. Explain экономит время и силы своих пользователей. Разработчики документации часто сталкиваются с проблемой многократного использования одного и того же фрагмента текста и прибегают к очевидным решениям - "Ctrl+c", Ctrl+v". Dr.Explain предлагает решение по повторному использованию контента - текстовые переменные. Это решение экономит время, когда нужно много раз использовать один и тот же текст, особенно, который может периодически изменяться - например, версия документируемой системы.

Многие российские компании сталкиваются с тем, что руководство пользователя нужно писать согласно ГОСТ 19 и ГОСТ 34. Dr.Explain активирует поддержку требований ГОСТ фактически одним кликом. Программа автоматически сформирует структуру обязательных разделов и установит требуемые параметры страницы, стили абзацев, списков и заголовков.

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

Попробовать режим многопользовательской работы в Dr.Explain можно даже с бесплатной лицензией. Вы можете создать общий проект и полноценно работать с ним в многопользовательском режиме до семи дней.

Почему компании выбирают Dr.Explain для создания руководств пользователя

Павел Свиридов, профессиональный военный, полковник, создатель астрологической системы "Вега Матрица"

"Только программа Dr.Explain обладала всеми необходимыми возможностями. А главное - она давала простор для творчества. Можно было выбрать цветовую гамму, вид и форму служебных элементов, настраиваемые шаблоны. Это позволило мне сохранить стилевое единство документации и самой программы. Ну, и конечно, полуавтоматическая обработка материала существенно облегчает и ускоряет работу по созданию хелпа.
Обучение работе в Dr.Explain было наглядным и сделано возможностями самой программы, что безусловно повлияло на мой выбор в ее пользу".

Прочитать полный кейс компании "Вега Матрица вы можете перейдя по ссылке

Наталья Обухова, бизнес-аналитик компании CRM Expert

Николай Вальковец, разработчик компании 2V

"Мы значительно сократили время работы техподдержки с новыми клиентами на этапе подключения. Раньше требовалось проводить онлайн презентации и видео конференции для новых клиентов, объясняя особенности программы. Сейчас же, один раз постаравшись максимально подробно всё описать, мы избавили себя и нашу техподдержку от этой работы. Нам импонирует простота программы и скорость работы. Можно быстро редактировать, добавить новые пункты в документацию, сохранить в формате HTML и выложить на сайт".

Прочитать кейс компании V2

Подытожим

Успешных вам разработок!

Смотрите также

СКАЧАТЬ
БЕСПЛАТНО
195 Mb, Windows 11/10/8/7 - 64 Bit

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

Итак, что такое компьютерная программа? ПО представляет собой последовательность инструкций, выполняемых ПК. Компьютер же – это любое устройство, способное обрабатывать код. Сюда относятся стационарные ПК, ноутбуки, планшеты, банкоматы, Raspberry Pi, серверы etc.

Разработка программного обеспечения и аналогия

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

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

Естественный язык компьютера

Машины пользуются своим собственным языком. Они не понимают русский, английский или испанский. Естественным языком электронного оборудования является двоичный код - 1 и 0. Он представляют собой два состояния: on (1), off (0).

Осваивайте языки программирования

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

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

Определение переводчиков

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

Переводчики могут быть любыми:

интерпретаторы;
компиляторы;
гибриды интерпретаторов и компиляторов;
ассемблеры.

Интерпретаторы

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

Python – хороший пример интерпретируемого языка программирования.

Компиляторы

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

Интерпретаторы работают построчно и выполняют одну линию перед тем, как перейти к следующей. Компилятор же переводит все строки программы в файл (двоичный) и выполняет его целиком.

Помните определение компьютерной программы? Это последовательность инструкций для компьютера. Выполнение программы обычно называется процессом. Такие ПО используют определенные ресурсы в компьютерной системе или любом другом девайсе. К ресурсам относятся память, дисковое пространство и файловая система.

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

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

Гибридные переводчики

Гибридный переводчик представляет собой комбинацию интерпретатора и компилятора. Популярным гибридным языком программирования является Java.

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

Ассемблеры

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

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

Часто задаваемый вопрос

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

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

Если вы заинтересованы в более подробном изучении вопроса, вот несколько хороших исследований.

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

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

В Windows встроенный терминал представляет собой командную строку. Для пользователей Mac и Linux по умолчанию установлен терминал Bash. Чтобы использовать его в Windows, установите Git Bash или PowerShell.

Двигаемся дальше

Приготовьтесь, ведь разработка программного обеспечения началась! Подготовимся к написанию первой строки кода. Для этого потребуется следующее:

Компьютерная система. Необязательно сложный или очень дорогой ПК. Подойдет просто компьютер, который хорошо работает.
Установка CLI. Вот хороший курс для начала работы.
Установка текстового редактора (например, Notepad++).
Понимание хотя бы одного языка программирования. Из статьи вы узнаете основные элементы, которые составляют фундамент большинства ЯП.

Читайте также: