И. Соммервилл - Инженерия программного обеспечения (1133538), страница 27
Текст из файла (страница 27)
бражать детальную информацию Подготовить краткий документ лля руководства компании, показывающий важность данного проекта для достижения финансовых целей компании Рассмотреть возможность покупки более производитель- ной базы данных Изменения требований Реорганизация компании- разработчика Недостаточная производи- тельность базы данных Рассмотреть вопрос о покупке системных компонентов, ис- следовать возможность использования генератора про- граммного кода Недооценки времени вы- полнения проекта Существует три категории стратегий управления рисками. Б Сюраэмгки яреуэям~ащеяия рискав. Согласно этим стратегиям следует проводить меро.
приятия, снижающие вероятность проявления рисков. Примерои может служить стратегия исключения потенцизльно дефектных компонентов, описанная в табл. 4.7. 2. Мкккккзавкоякмс сжраэмгик. Направлены на уменьшение возможного ущерба от рисков. Примером служит стратегия умсньщения ущерба от болезин членов команды разработчиков (см. табл. 4.7).
3. Пллнкуьманкс "лвлРкйнмл" пгтупкий. Согласно этим стратегиям необходимо иметь план мероприятий, которые следует выполнить в случае проявления рисковой ситуации. В табл. 4.7 это стратегия поведения прн возникновении финансовых про. блем у организации-разработчика. 4.4.4. Мониторинг рисков Мониторинг рисков заключается в регулярном пересчете вероятностей рисков и ущерба, который они могут нанести.
Для этого необходимо постоянно отслеживать факторы, которые влияют на вероятность рисков и возможный ущерб. Эти факторы зависят от типов риска. В табл. 4.8 приведены признаки, которые поиогают определить тип риска. 100 Часть 1. Инженерия программного обеспечеиият обзор Таблица 4.8. Признаки рисков Тин риска Признаки Задержки в поставке оборудования или программных средств поддержки процесса создания ПО, многочисленные документи. роааиные технологические проблемы Низкое моральное состояние персонала, натянутые отношения между членами команды разработчиков, низкое качество выпол- ненной работы Раэгоаоры среди персонала о пассивности и недостаточной ком- петентности высшего руководства органиэации Нежелание разработчиков использовать программные средства поддержки, неодобрительные отзывы о САБЕ-средствах, запросы на более мощные инструментальные средства Необходимость пересмотра многих системных требований, не- довольство заказчика ПО Технологические риски Риски, связанные с персоналом Организационные риски Инструментальные риски Риски, связанные с системными требова- ниями Риски оценивания Изменения графика работ, многочисленные отчеты о нарушении графика работ Мониторинг рисков должен быть непрерывным процессом, отслеживающим ход выполнения мероприятий по управлению рисками, при этом каждый основной риск должен рассматриваться отдельно.
йтгг 'вньнугэгн ргьт„",;ьугпге,," Ярткзлс-'гггжйго",'о0$~тр~;~ьтт~Щ'*ф"~:«'лггйебич: н !. югпвэ; 1 "' гнорвгу и„" '~з~рп КЛЮЧЕВЫЕ ПОНЯТИЯ.;айуф~~~рит~:.му:.'. ~уйржня- ~:;гияуаязти, .-'г! , ) '. ' ьсттзздзтиъжтмн.гж:фикшьм ьйлпглГьнчгбубрйлтга~~гагроб ' '; ' тдгат ~'.,шзс - ~ ° ' ПРИЭййЮМ".ЮРОШИо,уПРВЕЛЕЮГГГдрОПТИГЫНЫ9'йрСЕКПЭВГГРГЛяфай'",ПйрОбреф~эрррВКтцэа'СОбубЕт-„ йттуетПМИЛЗХХжаЛЬХу'ПрараММНОЕ.ОбЕСПЕЧЕНИП НЕЫВПГрнаЛЫИЬНОПЫтан Пц~анявииоа:-Прн:РЕВПИМцИИ: фрйанболее Ранниспооектоцгышквт окаэшьсп недостаттгтбогдлУ выРаботюмстРатегиилУпРавленин но-.
,"й~ ~ВЫМИ И СЛРЭЫЫМИ ПРСГГЮМГУНЫМИПРОЕКТВМН '~Ц Г0йРЕГРф$ГЕш,'ГЬ, Гйс -,,', .:4аеат „'.-~. В:..~. ';"";4',"являются планйгииэииопромпа,'оцвиеэние'ерегЭЕНГВ~п я 4йй: ресурсоВ ~иобэбдйгтгяГ Дяя реа." -ФФ.':"ЛнейЦИИ ПРОЕКШ а таюа СОСтВВНЕНйЕ:ТРафйха Рвбот, ПяййиРОВЗНИЕ ПР4йпа И ОЦЕйййУвйи НЕОбс" :,.=-- ходимых ресурсов — это итерационные енды деятельности, кпюрые продфпаюгся'в те ение Всц-„' РЧ,";;.',.ЛП СРШЗ',ВЫПОЛНЕНИЯ ПРРЕКШ, ДО'МЕРЕ.'ПсотУйЛЕНИЯ,ДОГЮРбИтЕРЬНОб ИЦфОРЫИВОГ,9ДРДЕ ВЫПОТвме!'," м 'Юя Пйовхта ЛЛВГШ И ГРВфИКИ Мстуг ПЕРЕСМВТРИВШЬСВШ: Э'-.»„„."„',Г"..
ффе~~ ..',,д„',ЫЬ '~ -,...."ежб уеэ,'.;ЬНтРОЛЬНЫЕзсиип И-. ЭТО ПРОШЮЗНРУИЗЫВ,.',ИЛХОДЫ"сзтабоа РРаЮГРМашг ПРОЕКПЮ,'ВРГОРЬЮ СоэГчвоь-",: 9"'"' 'спю с обсчетом о вйпнменни агапа передастся "рукоеоэстэу"грсрктоы. ~онтрряжые проекпьге эле. менты-это юнтроаные отметки, ппсрые пйедсртавйются йэ ВэчйкуЪрограммнбйсистемы.: -,:.- ;". °,.'- сСОСтэелвиив ГРафизха 'Рабст СОСУснт В СОЮТТВУГИИРВЗЛИУ~ЫХзГРафИ~ЕСЮГХ ПРЕДСтаВЯюинй;ОтУЛЬРЫХ:з -'„:.:,;частей плана проеМ, сюда отвхитсл сетевые диагрэьгмы атайов;"'гаягаэыппюпше вэаимоэависит,.
;„;-,ятй моста шаюв работ, и еременнпг диираммы дипельиостн этапа .ъ:.„:„; -, мй бч ж мшн1бф- . йуааДпяяобио,лровхта дШПЫЫ бЫтЬ РПрЕдЕПЕйЫЛШЮИейатрИСВИ,я ТИПЮ ПерсяпгЮСТЫК ОС9цротвяаьц ;-~'-.'-',,НИя И ИрыожНЫй рцерб От ИИХгДЛП Нанбсяев ВЕРОЭтНЫХ РГЮРИЛОСЛадртэьйЬртхППСРЬИ браевлвзт Г ,ь' .„-',сеРыюны, РаэоабэтыипшснмеРОпринпи до ихлгдцзпгрицэганоили гэнгженюоеОэмОхмбгР Упюйбаат 4. Уираиленне проектами 101 Упражнения Таблица 4.9. Этапы проекта Длительности (дии) Зависимость 10 Т1 Т1 15 Т1, Т2 Т5 10 Т4 20 Т5 10 Т5.
Т4 ТБ 15 Т5 Т7 20 Т8 Т6 15 Т9 Т5, Т9 Т10 Т9 Т11 1О 20 Т10 Т12 Т5, Т4 Т13 ТБ, Т9 Т12. Т14 10 Т14 20 Т15 Т15 Т16 1О 4.1. 4.2. 4.3, 4.4. 4.6. 4,6. Обьясните, почему нематериавьность программных систем порождает особые проблемы в процессе управления программными проектами. Объясните, почему хорошие программисты не всегда мшут быль хорошими менеджера прошпов. Для построения объяснения может помочь список работ, выполняемых менеджером проеюов (см. раздел 4Л ). Обьясните, почему процесс планирования проекта яшмется итерационным и почему план должен постоянно пересматриваться в течение всего срока выполнения проекта.
Опишите кратко каждый раздел плана выполнения программного проекта. В чем принципиальнов различие между кошролыюй отметкой и кшпрольным программньел элемшпом2 В табл. 4.9 показаны этапы некоего прсшкта, их длительность и взаимозависимость между ними. На- рисуйте сетевую и временную диаграммы атапов работ для данного проекта 102 Часть 1. Инженерия программнога обеспечения: обзор 4.7. В табл, 4.2 приведена длительность этапов некоторого проекта. Предположим, что вследствие неких серьезных причин этап Тб был выполнен за 40 дней вместо запланированных 10 дней.
Переделайте сетевую диаграмму этапов и определите новый критический путь. Нарисуйте новую временную диаграмму. 4.0. В дополнение к рискам, приведенным в табл. 4.б, определите еще шесть рисков, которые возможны во время реализации проекта. 4.9. Менеджер проекта предупреждает а возможной задержке выполнения работ, которой можно избежать только за счет бесплатных сверхурочных работ команды разработчиков. Все члены команды имеют семьи, требующие определенной доли внимания. Обсудите возможность отклонения предложения менеджера о бесплатных сверхурочных работах либо согласия предпочесть интересы организации семейным интересам, Какие аргументы наиболее весомы в этой дискуссии? 4.10. Как опытному программисту, вам предложили возглавить управление проеквм, но вы чувствуете, что больше пользы можете принести в качестве технического специалиста, а не менеджера проекта.
Обсудите возможности принятия или отклонения предложения возглавить программный проект. Требования к программному обеспечению Цель настоящей главы — дать основныс понятия требованиях, предъявляемых к программным сис мам, и показать различные способы представлен этих требований. Прочитав зту главу, вы должны: О иметь понятие о концепциях пользовательских системныхтребоваиий и знать, почемудля запн этих требований используются разные способы; О понимать различия между функциональными нефункциональными требованиями; О освоить два метода описания системных трос наний: основанный на структурированном сс1 ственном языке и основанный на языке пг грачмирования; О знать стандарты документирования трсбованиг программному обеспечению. ~~5Яер '.
" 5.1. Функциональные и нефункциональные требован~ 5.2. Пользовательские требования 5.3. Системныс требования 5.4. Документирование системных требований 106 Масть 11. Требования Проблемы, которые приходится решать специалистам в процессе создания программного обеспечения, обычно очень сложны.
Природа этих проблем не всегда ясна, особенно если разрабатываемая программная система инновационная. В частности, трудно четко описать те действия, которые должна выполнять система. Описание функциональных возможностей и ограничений, накладываемых на программную систему, называется ж)зебааанклми к этой системе, а сам процесс формирования, анализа, документирования и проверки этих функциональных возможностей и ограничений — разрайяэкай жрэбэваний (гсцщгстепи епя!пееппя). В этой главе внимание концентрируется на самих требованиях и способах их описания.
Процесс разработки требований в общих чертах описан в главе 3, а более подробно освещен в следующей главе. Термин эфебовакия (к программной системе) может трактоваться по разному. В неко. торых случалх под требованиями понимаются высокоуровневые обобщенные угвержде.
ния о функциональных возможностях и ограничениях системы. Другая крайняя ситуация — детализированное математическое формальное описание системных функций. Дэвис (Паты) (89) так объясняет причины этих различий. Если компания хочет выиграть контракт на разработку большого программного проекта, она вынуждена, пока решение не принято, представлять требования в самом обобщенном виде, чтобы, с одной стороны, удовлетвцэить требования заказчика, а с другой — иметь возможность для маневра при конкуренции с другими компаниями-разработчиками. После того как контракт выигран, компания должна п)идставить заказчику более подробное описание системы с указанием всех выгюлняшэых ею функций.
В обеих ситуациях предоставляются документы, которые называются документированными требованиями к системе. Некоторые проблемы, возникающие в процессе разработки требований, порожцены отсутствием четкого понимания различия между этими разными уровнями требований. Чтобы различить требования разных уровней, здесь используются термины ятмыоэамел скке требования (нксг гет)шгептепы) для обозначения высокоуровневых обобщенных требований и сисэмннмг мумйманил (зуметп гет)ейгетепы) для детализированного описания выполняемых систечой функций. Кроме требований этих двух уровней, применяется еще более лстализнрованнос описание системы — арсекжная атгэмнная гаеиификаиил (эоймаге без!яп зрес!Псайоп), которал может служить мостом между этапом разработки требований и этапом проектированил системы.
Три перечисленных вида требований можно определить следующим образом. 1. Палыаеамгльсккг тгх6аванил- описание па естественном языке (плюс поясняющие диаграммы) функций, выполплемых системой, и ограничений, накладываемых на нее. 2. Сигэмкяые эулбмакэя — детализированное описание системных функций и ограничений, которое иногда называют функциональной спецификзцней. Она служит основой для заключения контракта между покупателем системы и разработчиками ПО. 3. Праекэтная скгэимнал слгикфккаикя- обобщенное описание структуры программной системы, которое будет основой для более детализированного проектирования системы и се последующей реализации. Эта спецификация дополняет и детализирует спецификацию системных требований. Различие между пользовательскими и системными требованиями показаны в примере, прсдставлсннокг в табл.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
