И. Соммервилл - Инженерия программного обеспечения (1133538), страница 22
Текст из файла (страница 22)
3.8. Объясните, почему в процессе определения требований необходимо различать разработку пользовательских требований и разработку системных требований. 3.9. Опишите основные этапы процесса проектирования ПО, ?пиите выходной результат каждого этапа. С помощью диаграммы "сущность-связь' покажите возможные взаимосвязи между выходными результатами разных этапов процесса проектирования. 3.10. Назовите пять основных компонентов любых методов проектирования.
Какие методы проекгирования вы знаегв? Опишите их компоненты. Оцените полногу этих методов. 3.11. Разработайге модель процесса тестирования исполняемой программы. 3.12. Покажите, как классификация САЗЕ-технологий мажет помочь менеджеру в процессе приобретения САЗЕ-систем. 3.13. Опишите САЗЕ-средства, которые можно использовать в вашем рабочей среде разработчика, и классифицируйте их по нескольким параметрам (выполняемая функция, поддерживащлый процесс, количество поддерживаемых процессовй 3.14. Известно, что внедрение любой новой технологии значительно влияет на рынок рабочей силы и (по крайней мере временно) увеличивает уровень безработицы, Обсудите возможные последсгвия внедрения САЗЕ-технологий для специалистов по программному обеспечению.
Уменьшат ли эти технологии занятость разработчиков ПО? Если вы считаете, что уменьшат, то этичны ли действия специалистов, внедряющих САЗЕ-технологии? Управление проектами ф~ф Цель настоящей главы — обзор процсссов управлсни программными просктами. Прочитав эту главу, в~ должны:, понимать различия между управлсннсм прс граммными проектами и управлсиисм инжснс1 ными проектами других типов; знать основные задачи, стоящие перед рукоаодь толом программного проекта; понимать значимость и роль этапа плапнровани проскта срсди всех этапов процесса создани ПО; Ы знать графические способы представления гр фиков работ; С1 иметь представление о типах рисков, возникак щих при рсэлизации програмчных проектов, ~ процессы управления этими рисками.
о е', 4.1. Процсссы управления 4.2. Планирование проекта 4.3. График работ 4.4. Управление рисками 82 Масть Е Инженерия программного обеспечения: обзор Проблемы управления программными проектами впервые проявились в 60-х — начале 70-х голов, когда провалились ьшогис большие проекты по разработке программных продуктов. Бьыш зафиксированы задержки в создании ПО, оно бьио ненадежным, затраты на разработку в несколько раз иревосходилн первоиачэльиыс оценки, созданные программные системы часто имели низкнс показатели производительности 160).
Провалы этих проектов обусловливались не только искомпстс~ггпосгью руководителей и программистов. Напротив, в этих больших поигковьш прослгах пронимали участие люди, уровень ююлифиюции которых был явно выше грслнсго. П1яишиы провалов корсиилигь а тсх подходах, которые использовались в упраплеиии проектами. Приыспясмая методика была основана на опыте управлешш техническими проскталш и оказалась неэффективной при разработке программного обеспечения.
Здесь важно понлть разницу между профессиональной разработкой ПО и любительским програлгмированием. Необходимость управления программными просктамн вытекает из того "прискорбного" факта, что процесс создания профессионального ПО всегда является субъслтом бюджетной политики организации, где оно разрабатывается, и имеет врсмснныс ограничения. Работа руководителя программного проекта по большому счету заключается втоц, чтобы гарантировать выполнение этих бюджетных и временных огра. ничсний с учетом бизнес.целей оршнизации относительно разрабатываемого ПО. Менеджеры проектов призваны спланировать все этапы разработки программного продукта.
Оцн также должны контролировать ход выполнения работ и соблюдения всех требуемых станлартов. Постоянный контроль за ходом выполнения работ необходим для того. чтобы процесс разработки не выхолил за врсмеиныс и бюджетные ограничения. Хорошее управление не гарантирует успешного завершения проекта, но плохое управление обязательно приведет к его провалу. Это может выразиться в задержке сроков сдачи готового ПО. в превышении сметной стоимости проекта и в несоответствии готового ПО спепнфикации требований. Руководители программных проектов выполняют такую же работу, что и руководители технических проектов. Вместе с тем процесс разработки ПО существенно отличается от процессов реализации технических проелтов, что порождает определенные сложности в управлении программныии ироекталпь Приведем небольшой список этих отличий.
1. Прозуяиитый л/юдукгя ягчяпиуагмгк. Менеджер судостроительного проекта или проек. за постройки ащшия видит результаты выполнения своего проекта. Если реализация проелта отстает от графиню это также видно воочию, так как часть конструкции не завершена В противоположность этому программное обеспечение нематериально. Его нельзя увидеть или потрогать. Менеджер программ ного проекта не видит процесс "рости" разрабатываемого ПО.
Оп может полагаться только на документацию, которая фиксирует процесс разработки программного продукта. 2. П'пэягаявуж гзикдяряигых н~юягигюульуюботхя ПО. На сегодняшний день ис существует четкой зависимости между процессом создания ПО и типом создаваемого программного продукта. Другие технические дисциплины илгсют длительную историю, процессы разработиг технических иэделий ьшогократно опробованы и проверены.
Процессы создания большинства технических систем хорошо изученья Изучением же процессов создания ПО специалисты занимаются только несколько последних лет. Поэтому пока нельзя точно ирслскаэать, на каком этапе процесса разработки ПО могуг возникнуть п робле мыс угрожающие всему и рограммиому проекту. 3. Бплыяиг ярогразьчные кумганы — ээю чяояо "одноразовые" яяогкягы Большие программиыс проелты, как правило, значительно отличаются от проектов, реализованных ранее.
Поэтому, чтобы уменьшить нсопрелелеииость в планировании проекта, руководители проектов должны обладать очень большим практическим опытом. Но постояниыс технологические изменения в компьютерной технике и коммуникационном оборудовании обссценивак~т предыдущий опыт. Знания и навыки, накоп. леиныс опытом, могут ис востребоваться в иовом проекте. 4. Управление проектами 83 Перечисленное выше может привести к тому, что реализация проекта выйдет из вре менпого графика или превысит бюджетные ассигнования.
Программные системы зачастую оказываются новинками как в "идеологическом", так и в техническом плане. Технические проекты, которые являются инновационными (например, новал транспортная систелга), также часто нарушают временные графики работ. Поэтол~у, предвиля возможные проблемы в реализации программного проекта.
следует всегда полгнить, что многим из них свойственно выходить за рамки временных и бюджетных ограничений. Управление программными проектами — тема весьма обширная, которую невозможно осветить в одной главе. Поэтом> в настоящей главе дается только введение в эту тему и рассматривается три основных процесса, выполняелгых в рамках > правления проектами, а именно: планирование проекта, составление графика работ и управление рисками. В части У) представлены другис аспекты управления проектами разработки ПО, в том числе управление персоналом, оцепивание стоимости проекта и управление качеством ПО.
4.1. Процессы управления Невозможно описать и стандартизировать все работы, выполнлемые менеджером проелта по созданию ПО. Эти работы весьма существенно зависят от организации, где выполняется разработка ПО, и от типа создаваемого программного продукта. Но в любом случае большинство менеджеров ответственны за выполнение всех пли некоторых из приведенных ниже процессов управления.
° Написание предложений по созданию ПО. ° Планирование и составление графика работ по созданию ПО. ° Оцсниванис стоимости проекта. ° Контроль за ходом выполнения работ. ° Подбор персонала. ° 11аписапие отчетов и представлений. Первая стадия программного проекта может состоять из написания прелложений по реализации этого проекта.
Предложения должны содержать шпшание целей проектов и способов нх достижения. Они также обычно включают в себя оценки финансовых н временных затрат па выполнение проекта. При необходимости здесь могут приводиться обоснования для передачи проекта на выполнение сторонней организации или команде разработчиков.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
