Что является отправной точкой компьютерной программы

Обновлено: 22.01.2025

Программы, написанные на языках программирования высокого уровня, перед выполнением на ЭВМ должны транслироваться в эквивалентные программы , написанные на машинном коде. Транслятор – это программа , которая переводит программу на исходном (входном) языке в эквивалентную ей программу на результирующем (выходном) языке. Если исходный язык является языком высокого уровня, например, таким как Паскаль , С++, и если объектный язык – автокод , то такой транслятор называется компилятором.

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

Другой метод реализации программ, написанных на языке высокого уровня, – интерпретация [21]. Интерпретатор программно моделирует машину, цикл выборки-исполнения которой работает с командами на языках высокого уровня, а не с машинными командами. Такое программное моделирование создает виртуальную машину, реализующую язык. Этот подход называется чистой интерпретацией. Чистая интерпретация применяется, как правило, для языков с простой структурой (например, АПЛ или Лисп ). Интерпретаторы командной строки обрабатывают команды в скриптах в UNIX или в пакетных файлах (.bat) в MS-DOS , как правило, также в режиме чистой интерпретации.

Достоинство чистого интерпретатора: отсутствие промежуточных действий для трансляции упрощает реализацию интерпретатора и делает его удобнее в использовании, в том числе в диалоговом режиме. Недостаток – интерпретатор должен быть в наличии на целевой машине, где должна исполняться программа . А свойство чистого интерпретатора, что ошибки в интерпретируемой программе обнаруживаются только при попытке выполнения команды (или строки) с ошибкой, можно признать как недостатком, так и достоинством [20].

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

Для компиляции компилятор должен выполнить анализ исходной программы, а затем синтез объектной программы. Сначала исходная программа разлагается на ее составные части; затем из них строятся части эквивалентной объектной программы. Для этого на этапе анализа компилятор строит несколько таблиц (рис.4.2), которые используются затем как при анализе, так и при синтезе [12].

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

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

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

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

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

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

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

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

Более детальное представление о процессе компиляции можно получить в специальной литературе [12, 20, 21].

4.3. Понятие системы программирования

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

Основные технические средства, используемые в комплексе с компиляторами, включают в себя следующие программные модули [20]:

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

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

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

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

В качестве основных тенденций в развитии современных систем программирования следует указать внедрение в них средств разработки на основе так называемых языков четвертого поколения 4GL (four generation languages ), а также поддержку систем быстрой разработки программного обеспечения RAD ( rapid application development ).

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

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

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

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

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

1. Системное программное обеспечение (системные программы);

2. Прикладное программное обеспечение (прикладные программы);

3. Инструментальное обеспечение (инструментальные системы).

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

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

ОС определяет производительность системы, степень защиты данных, выбор программ, с которыми можно работать на компьютере, требования к аппаратным средствам. Примерами ОС являются MS DOS, OS/2, Unix, Windows 9х, Windows XP.

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

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

Для организации более удобного и наглядного интерфейса пользователя с компьютером используются программные оболочки операционных систем – программы, которые позволяют пользователю отличными от предоставляемых ОС средствами (более понятными и эффективными) осуществлять действия по управлению ресурсами компьютера. К числу наиболее популярных оболочек относятся пакеты Norton Commander (Symantec), FAR (File and Archive manageR) (Е.Рошаль).

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

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

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

 программы оптимизации и контроля качества дискового пространства;

 программы восстановления информации, форматирования, защиты данных;

 программы для записи компакт-дисков;

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

 коммуникационные программы, организующие обмен информацией между компьютерами и др.

Некоторые утилиты входят в состав операционной системы, а некоторые поставляются на рынок как самостоятельные программные продукты, например, многофункциональный пакет сервисных утилит Norton Utilities (Symantec).

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

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

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

 ППП общего назначения – универсальные программные продукты, предназначенные для автоматизации широкого класса задач пользователя. К ним относятся:

Текстовые редакторы (например, MS Word, Word Perfect, Лексикон);

Табличные процессоры (например, MS Excel, Lotus 1-2-3, Quattro Pro);

Системы динамических презентаций (например, MS Power Point, Freelance Graphics, Harvard Graphics);

Системы управления базами данных (например, MS Access, Oracle, MS SQL Server, Informix);

Графические редакторы (например, Сorel Draw, Adobe Photoshop);

Издательские системы (например, Page Maker, Venture Publisher);

Системы автоматизации проектирования (например, BPWin, ERWin);

Электронные словари и системы перевода (например, Prompt, Сократ, Лингво , Контекст);

Системы распознавания текста (например, Fine Reader, Cunei Form).

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

 методо-ориентированные ППП, в основе которых лежит реализация математических методов решения задач. К ним относятся, например, системы математической обработки данных (Mathematica, MathCad, Maple), системы статистической обработки данных (Statistica, Stat).;

 проблемно-ориентированные ППП предназначены для решения определенной задачи в конкретной предметной области. Например, информационно-правовые системы ЮрЭксперт, ЮрИнформ; пакеты бухгалтерского учета и контроля 1С: Бухгалтерия, Галактика, Анжелика; в области маркетинга –Касатка, Marketing Expert; банковская система СТБанк;

 интегрированные ППП представляют собой набор нескольких программных продуктов, объединенных в единый инструмент. Наиболее развитые из них включают в себя текстовый редактор, персональный менеджер (органайзер), электронную таблицу, систему управления базами данных, средства поддержки электронной почты, программу создания презентационной графики. Результаты, полученные отдельными подпрограммами, могут быть объединены в окончательный документ, содержащий табличный, графический и текстовый материал. К ним относят, например, MS Works. Интегрированные пакеты, как правило, содержат некоторое ядро, обеспечивающее возможность тесного взаимодействия между составляющими.

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

К инструментальному программному обеспечению относят: системы программирования – для разработки новых программ, например, Паскаль, Бейсик. Обычно они включают: редактор текстов, обеспечивающий создание и редактирование программ на исходном языке программирования (исходных программ), транслятор, а также библиотеки подпрограмм; инструментальные среды для разработки приложений, например, C++, Delphi, Visual Basic, Java, которые включают средства визуального программирования; системы моделирования , например, система имитационного моделирования MatLab, системы моделирования бизнес-процессов BpWin и баз данных ErWin и другие.

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

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

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

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

Я подумываю о разработке программного обеспечения для Ubuntu и других родственных дистрибутивов Linux (таких как Linux Mint). Но в настоящее время я не понимаю, с чего начать.

Будет ли изучение Python достаточным /хорошим? И о чем я должен знать прежде, чем начать этот вид развития?

И могу ли я опубликовать свои приложения в магазине программного обеспечения, например в магазине Ubuntu, даже если я из-за пределов США /Великобритании? Если нет, то каковы параметры, которые я должен сделать, чтобы мои приложения доходили до аудитории?

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

В настоящее время я являюсь сертифицированным разработчиком Java Java-разработчика в J2SE и J2ME. И я немного знаю Python.

3 ответа

Вы можете начать с Python и Quickly, что довольно просто.

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

Учебное пособие по началу работы можно найти здесь .

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

Кроме того, пожалуйста, остановитесь с этой «аппетитной» ерундой. Здесь мы пишем приложения.

Какие приложения вы хотите написать?

Python + Qt может создавать превосходные графические приложения для Linux

Существует конференция по началу разработки приложений Liunux с переговоры онлайн

Я не знаю, если /почему Ubuntu ограничит доступ к программистам из США /Великобритании - см. программный центр для деталей

Некоторое время назад обратил свое внимание на артефакт Концепция продукта (product vision) методологии разработки программного обеcпечения RUP (Rational Unified Process) и обнаружил, что отправной точкой разработки программного продукта является выявление проблемы, на решение которой нацелен продукт.

Аналогичный подход существует и в отечественной практике – так в ГОСТ 34.601-90 говорится, что на стадии Формирование требований к АС (автоматизированной системе) производится «выявление проблем, решение которых возможно средствами автоматизации».

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

Общая характеристика процесса принятия решений

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

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

С чего начинается родина решение?

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

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

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

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

Задача

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

Операция и решение

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

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

Рисунок 1. Типовой процесс управления организацией

Оценка эффективности управленческого решения

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

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

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

Природа требований к программному продукту

Какая задача – такое и решение

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

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

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

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

Что такое требование?

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

Требование — свойство программного обеспечения, необходимое пользователю для решения задачи при достижении поставленной цели.

Уровни требований

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

Рисунок 2. Процесс создания автоматизированной системы

Потребность

Аналогично процессу выработки управленческого решения, анализируя проблему ЛПР формулирует цель автоматизации деятельности организации. Чтобы достигнуть цели, разрабатываемая система должна решать некоторый набор технических или бизнес-задач. В контексте разработки программного обеспечения эти задачи именуются потребностями (needs).

Функция

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

Программное требование

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

Оценка эффективности программного решения

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

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

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

Почему так получается?

Кто виноват и что делать?

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

Рисунок 3. Искажение требований

На рисунке 3 показан пример процесса, в ходе которого возникают искажения. Когда ЛПР осознал проблему и сформулировал цель деятельности по ее устранению он доводит перечень задач (T₀) до исполнителей — персонала организации. Допустим, что именно эти исполнители будут использовать разработанный позднее программный продукт, т.е. они будут являться его пользователями. Каждый из них по-своему понимает поставленную ему задачу и при формулировании требований к программному продукту исходит из своих предположений (T₁).

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

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

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

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

Рисунок 4. Соотнесение требований с проблемой

Более того, понимание решаемой проблемы позволит качественно управлять масштабом проекта – например, в первую очередь реализовать ту функциональность, которая решает 80% проблемы.

Как этого добиться?

Определение проблемы

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

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

Элемент	Описание
Проблема	[описание проблемы]
воздействует на	[перечень сторон, на которых оказывает влияние данная проблема]
результатом чего является	[описание воздействия данной проблемы на заинтересованных лиц и\или бизнес-деятельность]
Выигрыш от	[описание предлагаемого решения]
Может состоять в следующем:	[перечень основных преимуществ, представляемых решением]

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

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

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

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

Заключение

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

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

вовлечение в проект заинтересованных лиц (Executive management support) — 20%;
привлечение конечного пользователя (User involvement) — 15%;
управление масштабом проекта (Optimazation) — 15%.

Все вышесказанное подтверждает аксиому, что программные продукты создаются для пользователей. Ориентация на проблемы заинтересованных лиц и потребности реального (конечного) пользователя является залогом успешности проекта по разработке программного обеспечения. Уже на начальном этапе проекта пользователь должен быть привлечен к работе, как результат этого — определение проблемы (problem statement) и концепция продукта (product vision) должны показывать, что команда проекта ясно осознает решаемую проблему, понимает потребности пользователей и готова их удовлетворить.

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