Принципы работы с требованиями к ПО. Леффингуэлл (2002) (Принципы работы с требованиями к ПО. Леффингуэлл (2002).djvu), страница 14

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

Ответы па следующие вопросы помогут их обнаружить. ° Кто будет поставлять, использовать или удалять информацию из системы? ° Кто будет управлять системой? ° Кто будет осуществлять сопровождение систел>ы? ° Где будет использоваться система> ° Откуда система полу >ает информацию? ° Какие внешние системы будут взаимодействовать с системой? 68 Часть 1. Анализ проблемы Имея ответы на зти вопросы, аналитик может создать блок-схему, описывающую границы системы, пользователей и другие интерфейсы.

На рис. 4.5 представлена новая система ввода заказов на покупку и ее окружение. Клерк, вводит нв локулку Клерк, вылисывввт счет Грвницесиствыы Русс. 4.5. Система и ее окружение Точечная линия иллюстрирует границу системы для предлагаемого решения. Из рисунка видно,что основная часть нового приложения будет развернута в новой системе ввода заказов на покупку, но часть кода решения должна разрабатываться и разворачиваться в уже существующей унаследованной системе. Этап 5.

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

Многие пз них могут даже заставить нас пересмотреть изначально предполагавшиУтся технологический подход. Необходимо учитывать, что существуют различные источники ограничений (зконоьтические, технические, политические и т.д.). Ограничения люгут быть заданы Глава 4. Пять втвпов анализа проблемы 69 еще до начала работы (УНикакой новой аппаратурыГ'). но может получиться, что пам действительно придется их выявлять. Чтобы их выявить, полезно знать, на что следует обратить внимание.

В табл. 4.4 указзны возможные источники системных ограничений. Перечисленные в таблице вопросы помогут выявить большую часть ограничений. Часто полезно получить объяснение огра. ннчения, как для того, чтобы убедиться, что вы поняли его назначение, так и для того, чтобы можно было обнаружить (если такое произойдет), что данное ограничение больше ке применимо к вашему решению. Таблица 4.4. Возкгожные источники ограничений системы Образцы вопросов Источник ° Какие финансовые илн бюджетные ограничения следует учесть? ° Существуют лн соображения, касающиеся себестоимости н ценообразования? ° Существуют лн вопросы лицензирования? ° Существуют лн внешние нлн внутренние политические вопросы, влияющие на потенциальное решение? ° Существуют лн проблемы в отношениях между подразделениями? ° Существуют лн ограничения в выборе технологий? ° Должны лн мы работать в рамках существующих платформ нли тех.

пологий? °, Запрещено лн использование любых новых технологий? ° Должны ли мы использовать какие-либо закупаемые пакеты программного обеспечения? ° Будет ли решение создаваться для наших существующих систем? ° Должны лн мы обеспечивать совместимость с существующими решениями? ° Какие операционные системы и среды должны поддерживаться? ° Существуют ли ограниченна информационной среды или правовые ограничения? ° Юридические ограничения? ° Требования безопасности? ° Какими другими стандартами мы ограничены? ° Определен лн график? ° Ограничены лн мы существующими ресурсамн? ° Можем ли мы привлекать работников со стороны? ° Можем ли мы увеличить штат? Временно? Постоянно) Эавюмнческий Полатыческнй Текннческий Системный Эксплуатационный График и ресурсы После того как ограничения выявлены, некоторые из ннх станут требованиями к вовой'системе ("использовать МИР-систему, предлагаемую поставщиком нашей нынешней системы учета").

Другие ограничения будут оказывать влияние на ресурсы и планы реализации. Именно при анализе проблемы необходимо выявить потенци. зльные источники ограничений и понять, какое влияние каждое ограничение окажет на область возможных решений. 70 Часть 1. Анализ проблемы Возвратимся к нашему примеру. Ограничения, которые могут налагаться на новую систему ввода заказов на покупку, представлены в табл. 4.5. Таблица 4.Ь. Ограничения, налагаемые на систему ввода заказов на покупку Источник Объяснение Ограничение Эксплуатационный Копия данных зазаза на покуп«у должна оставаться в унаследованной базе данных в течение одного года Системы н операци- онные системы Средства, выделен- ные на оборудование Фиксированный штат; не привле- кать работников со стороны Средства, выделен- ные на оплату труда персонала Технологические требования Фиксированные расходы на зарплату оо отношению к те«ушему бюджету Мы надеемся, что зтв технология по.

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

° Выявили заинтересованных лиц, чье коллективное суждение в конце концов будет определять успех или неудачу нашей системы. ° Выяснили, где, по всей видимости, должны находиться границы решения. ° Поняли существующие ограничения и определили степень свободы, которой мы обладаем при решении проблемы. Далее... Основываясь на полученных знаниях, мы можем перейти к рассмотрению двух специальных методов анализа проблем, которые можно применять в определенных предметных областях. В главе 5 «гы рассмотрим бизнесзшделирование, метод, который можно применить для 1$/1Т-приложений. В главе б будет описано системное проехав)>оеакш систем, интенсивно использующих прс» граммное обеспечение — наиболее подходящий метод анализа проблем при создании приложений в области встроенных систем. Что касается 1эЧ-приложений (разрабатываелзых неэависимылги прс» изводителями программного обеспечения).

методы анализа проблемы для них, как правило, заключаются в следующем. Приложение должно занимать на сервере не более 20 мегабайт Система должна быть разработана на существующем сервере пли хос- те; можно предложить новое кли- ентское аппаратное обеспечение лля пользователей Риск потери данных слишком вы- сож нам необходимо работать па- раллельно в течение года Количество доступной памяти сер- вера ограничено Сокращение издержек н поддержка существующих систем Глава 4. Пять агапов анализа проблемы ° Выявлснис имеющихся на рынке возможностей и существующих ниш ° Определение классов потенциальных пользователей и их потребностей ° Изучение демографии потенциальной пользовательской базы ° Оценка потенциального спроса, цен и эластичности спроса ° ! 1онимание стратегии продаж и организации каналов сбытов Это, безусловно, интересные вопросы, по, чтобы справиться с пал~счеппыми в данкой кинге задачами, мы пе будем подробно обсуждать их.

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

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

Аналогично команда может кспояьзовать "мозговой впурм" как для выявления возможных причин возникновения проблемы на этапе анализа проблемы, так и для определения возможных новых фупкяий системы, как это делается в главе 11. Мы не будем пытаться описать все ситуации, в которых будет применяться определенный метод. Вместо этого мы уделим основное внимание тому, чтобы команда овладела этими навыками, могла добавить в свой арсеяал эти методы и использовать их в нужный момент. Глава 5 Моделирование бизнес-процессов Основные положении - 1 ' ° Для анализа проблем в среде Б/1Т наиболее подходящим' является метод 1 моделирования бизнес-процессов. И Модель бизнес. процесса помогает иам при определении систем и их при- '( ложений. ° Модель прецедентов бизнес-процесса, состоящая из акторов и'прецеден-, '.