Исследование предметной области рассматриваемого бп
 Скачать 418.61 Kb.
|
                                   1. Исследование предметной области рассматриваемого БП.Под управлением проектом подразумевается деятельность, направленная на реализацию проекта с максимально возможной эффективностью при заданных ограничениях по времени, в денежных средствах и материальных ресурсах, а также по качеству конечных результатов проекта (документированных, например, в техническом задании). Управление как процесс характеризуется следующими компонентами:
Управление проектированием, как правило, рассматривают в двух аспектах: функциональном и организационном. Функциональный аспект определяется последовательностью работ по созданию проекта. Методология создания ИС отражена в нормативных документах, подавляющее большинство которых имеет силу международных стандартов. В них определены терминология, порядок создания и внедрения, требования к частям, состав проектов. Последовательность работ, связанных с определением целесообразности создания, созданием и промышленной эксплуатацией информационных систем (ИС), оформлена в виде процесса (создания или изготовления), который имеет иерархическое описание и состоит из стадий. Каждая стадия состоит из этапов, а этапы, в свою очередь, из видов работ. Ими реализуется функции управления на протяжении всего жизненного цикла ИС, который включает фазы “зарождение”, “создание и внедрение”, “эксплуатация”, “демонтаж”. Важнейшей фазой жизненного цикла ИС является фаза “создание и внедрение”, которая состоит из шести стадий: технико – экономическое обоснование (ТЭО), техническое задание (ТЗ), технический (ТП) и рабочий (РП) проекты, внедрение (Вн), анализ функционирования. Процесс создания и внедрения включает следующие стадии, этапы и некоторые виды работ. Стадия 1. Технико-экономическое обоснование (ТЭО). Основная цель работ этой стадии состоит в формировании обоснованного с позиций заказчика системы предложения о создании ИС с определенными основными функциями и техническими характеристиками. Основными выходными документами на этой стадии являются: ТЭО создания ИС и исходные технические требования к ИС в объеме, соответствующем ГОСТ. Стадия 2. Техническое задание (ТЗ). Основными целями стадии являются: подтверждение целесообразности и детальное обследование возможности создания эффективной ИС с функциями и техническими характеристиками, сформулированными в виде исходных технических требований к системе, планирование совокупности всех НИР, ОКР, проектных и монтажноналадочных работ, сроков их выполнения и организаций исполнителей, подготовка всех материалов, необходимых для выполнения проектных работ. Выходными документами стадии являются: ТЗ на создание ИС, содержащее технические требования и план – график работ, согласованные Заказчиком и основным исполнителем; уточненное технико-экономическое обоснование намеченных в ТЗ решений (при необходимости); научно – технический отчет, содержащий результаты проведенных предпроектных исследований; эскизный проект ИС. Стадия 3. Технический проект (ТП). Целями работ, выполняемых на этой стадии, являются разработка основных технических решений по создаваемой системе и окончательное определение ее сметной стоимости. Работы этой стадии завершаются разработкой: общесистемных решений, необходимых и достаточных для выпуска эксплуатационной документации на систему в целом, входящей в состав раздела “Автоматизация” технического проекта строительства; проектов заявок на разработку новых технических средств; документации специального математического и информационного обеспечения, включая техническое задание на программирование. Основные результаты работ стадии оформляются в виде технического проекта ИС. Стадия 4. Рабочий проект (РП). Целью работ, выполняемых на этой стадии, является выпуск рабочей документации на создаваемую систему. Работы на этой стадии завершаются выпуском рабочего проекта ИС, состоящего из проектной документации, необходимой и достаточной для приобретения, монтажа и наладки комплекса технических средств системы и документации и программного организационного обеспечений, необходимых и достаточных для наладки и эксплуатации системы, и изготовлением программ специального программного обеспечения на машинных носителях Стадия 5. Внедрение (Вн). Цель стадии и главный результат работ, выполняемых здесь – передача действующей системы в промышленную эксплуатацию. Стадия 6. Анализ функционирования (АФ). Цель работ, выполняемых на этой стадии, состоит в получении систематизированных и объективных данных о качестве создаваемой системы, текущем состоянии и реальном эффекте функционирования системы на основании опыта ее промышленной эксплуатации. Анализ функционирования выполняется в ходе промышленной эксплуатации и не ранее, чем через полгода со дня сдачи в промышленную эксплуатацию. С этой целью определяются показатели эксплуатационной надежности для системы в целом и для отдельных реализуемых ею функций, показатели техника экономической эффективности системы, функционально алгоритмическая полнота (развитость) системы и социально – психологическая подготовка персонала системы. Здесь же выносится решение о возможности дальнейшей эксплуатации системы, ее модернизации и дальнейшем развитии. Организационные формы управления проектированием ИС. В общем случае организационная структура управления проектированием регулирует взаимоотношения подразделений и должностных лиц в организации, устанавливает распределение ролей, полномочий и ответственности между ними, а также порядок функционально-технических связей, возникающих в процессах управления. Организационная структура и организационный механизм как система связи в данной организации образуют организационные формы управления деятельностью коллектива. Можно передать в распоряжение разработчиков самые совершенные средства проектирования, четкие формы документации, планы работ, методы контроля, но без должной организации не получить проект, удовлетворяющий потребностям заказчика. И наоборот, совершенная форма организации проектирования может компенсировать недостаток эффективных средств проектирования и в отдельных случаях даже квалификацию разработчиков. Матричный принцип построения организационных структур предполагает формирование в организации – разработчике ЭИС из специалистов функциональных подразделений проектных групп для разработки конкретных проектов. При этом специалисты не теряют принадлежности к соответствующему функциональному подразделению и находятся в двойном подчинении: у руководителя проекта (ответственность по проекту) и у руководителя функционального подразделения (организационная ответственность). Матричные структуры применяются в условиях высокой степени кооперации функциональных подразделений. Эти структуры основаны на особом механизме взаимодействия функциональных и проектно-целевых подсистем аппарата управления проектной организации. Главная особенность матричных структур состоит в обязательном выделении конкретного лица – руководителя проекта, наделенного всей полнотой ответственности за достижение цели проектирования и значительными правами распорядительства, которые делегируют ему вышестоящим руководством. Выбор целесообразного разделения труда разработчиков ИС зависит от ряда факторов, влияющих с разной степенью на решение проблемы. Наиболее существенными факторами являются следующие:
Структуры проектной группы Открытая организационная структура проектной группы отличается тем, что закрепленного организационного распределения обязанностей нет. Каждый член коллектива разработчиков является неформальным руководителем на этапе разработки системы, где он более других квалифицирован. Обязанности на  2. Определение структуры БП. 2.1. Дерево процессов. Обсуждение требований к программе оговор сроков выполнения работы получение систематизированных и объективных данных о качестве созданной программы выпуск рабочей документации на созданную систему разработка основных технических решений по создаваемой системе и окончательное определение ее сметной стоимости определение последовательности работ по созданию проекта Передача всех требований заказчика к ПО программистам Передача действующую систему в промышленную эксплуатацию обсуждение стоимости ПО Написание программного обеспечения Подписание договора с клиентом Управление выполнением заказов организации-разработчика программного обеспечения 2.2. Определение ресурсных потоков (входов/выходов) БП.
2.3. Определение границ БП.
2.4. определение роли участников БП (оперограмма БП).
3. Построение общей схемы выполнения БП  4. Управление и совершенствование бизнес-процесса. 4.1. Анализ бизнес-процесса.
4.2. Редизайн и реинжиниринг БП. Проблема БП заключатся в дороговизне и большом промежутке времени написания ПО. Целью редизайнинга бизнес процесса является сокращения времени написания программного обеспечения и снижения его стоимости. Достичь этого поможет упразднение отдела тестирования и перенос его полномочий на программистов. В связи с этим программистам потребуется применить в своей работе иную методологию разработки – TDD (TestDrivenDevelopment), а также полное покрытие кода модульными тестами. Это поможет не только снизить затраты на тестирование продукта, но и увеличить скорость разработки и количество ошибок в ПО посредством укорачивания итераций в цикле разработки. Согласно статистике, применение подобных методологий позволяет сократить количество ошибок на 80% путём ликвидации их еще на стадии написания кода. Направления совершенствования процесса: 1. Какие операции будут выполняться.
2.Будут ли операции, подпроцессы, работы выполняться и при каких условиях.
3. Кто будет выполнять операции, работы, подпроцессы.
4. Когда это будет происходить. Все процессы выполняются последовательно и непрерывно. 5. Где они будут выполняться. Все процессы выполняются в офисе компании-разработчика. 6. Насколько точно они будут выполняться. 7. Какая информация будет при этом использоваться. Определение требований, написание UserStories. Структура и особенности работы предприятия заказчика, а также словесное описание требований к разрабатываемому ПО. 8. Кто будет руководить процессом.
4.3. Оценка бизнес-процесса. По каким показателям будет оцениваться успешность процесса.
4.4. Рекомендации по совершенствованию качества бизнес-процесса Выбрал Пять «почему?». Почему разработка ПО затягивается? Длинные итерации написания кода и его проверки. Почему итерации длинные? Из-за того, что сначала пишется код, затем вручную тестируется QA (QualityAssurance). Почему ПО тестируется вручную? Тестирование – это сложный процесс, который в данном случае может проводиться только в полной интеграции всех модулей, а не каждого модуля по отдельности Почему мы не можем тестировать каждый модуль по отдельности? Модульное тестирование не может проводиться качественно силами QA. Только разработчиками Почему разработчики не проводят модульное тестирование? Модульное тестирование не используется в данной компании | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||