Техническое задание на разработку ис «Туристическая фирма»
Информационная система «Туристическая фирма».
1.2. Область применения
Данная разработка предназначена для применения в туристической фирме «Вираж».
1.3. Основание для разработки
Информационная система разрабатывается в рамках лабораторных работ по дисциплине «Проектирование и разработка информационных систем».
2. Назначение, цели и задачи ПО
2.1. Назначение разработки
Программа предназначена для использования сотрудниками туристической фирмы «Вираж» с целью автоматизации системы управления турфирмы.
Программное средство должно обеспечить ввод, хранение и просмотр информации о клиентах, заказах, поставщиках, сотрудниках, турах и услугах. Основной задачей данной информационной системы является помощь пользователю быстро оформить путевку, просматривать отчеты о заказах, турах, услугах.
3. Технические требования к программе или программному изделию
3.1. Требования к функциональным характеристикам
3.1.1. Функциональные требования
Программа должна обеспечивать возможность выполнения следующих функций:
ведение справочников номенклатуры городов, услуг, туров, транспорта, стран, сотрудников, заказов, клиентов, поставщиков;
вывод информации о стоимости туров;
вывод информации о турах в определенные страны с определенной длительностью пребывания;
ведении истории заказов клиентов;
формирование списка сотрудников, клиентов, поставщиков.
3.2. Исходные данные
информация о турах, сотрудниках, клиентах и заказах.
3.3. Требования к безопасности
В разрабатываемой системе необходимо предусмотреть следующие меры защиты:
контроль вводимой информации;
защиту от несанкционированного доступа посредством паролей;
возможность резервного копирования;
возможность автоматического сохранения изменений после завершения транзакций.
3.4. Требования к надежности
Разрабатываемая система должна соответствовать требованиям надежности:
обеспечение устойчивого функционирования;
автосохранение вводимой информации;
обеспечение целостности данных.
Надежность должна обеспечиваться за счет соблюдения правил эксплуатации и технического обслуживания программно-аппаратных средств, а также предварительного обучения пользователей.
Для правильного обеспечения работоспособности программы необходимо вносить данные только в том формате, который требуется программой. Для обеспечения лучшей работоспособности не рекомендуется выполнять сразу несколько одновременных операций, поскольку это может замедлить скорость обработки команд.
3.5. Условия эксплуатации
Программное средство должно быть рассчитано на профессионального пользователя. При работе пользователя с разрабатываемой информационной системой не должно возникать проблем, так как система обладает понятным программным интерфейсом.
Запрещается эксплуатация, а также модификация программы с целью нанесения вреда операционной системе другого пользователя. Запрещается использование программы на ЭВМ, которые не имеют антивирусной защиты, поскольку вредоносные программы могут нанести существенный вред работоспособности программы.
Разрабатываемый программный продукт необходимо эксплуатировать в следующих условиях:
регулярная проверка исправности и работоспособности операционной системы и оборудования, переустановка и замена по необходимости;
проверка баз данных на наличие ошибок и неисправностей в конце рабочего дня;
Практические работы / Практическая работа №1 по МДК 02.01
Практическая работа №1
Тема: Проведение анализа информационного, технического, программного, математического и иного обеспечения информационной системы
Цель: описать и проанализировать ИС, определить необходимые элементы КТС ИС и системного ПО ИС.
Выберите предметную область, соответствующую порядковому номеру списка группы.
Выберите название ИС в рамках предметной области.
ИС для заказа билетов на поезд.
Определите цель ИС
Целью данной ИС является обеспечение заказов билетов на поезд в сети Интернет.
Проведите анализ осуществимости ИС
Что произойдет с организацией, если система не будет введена в эксплуатацию?
Не будет обеспечена максимальная скорость передачи информации клиенту, а так же востребованность железнодорожного транспорта будет не высока, что ведет к упадку прибыли.
Какие текущие проблемы существуют в организации и как новая система поможет их решить?
К текущим проблемам организации относятся: не эффективное распределение и систематизирование больших потоков информации, не удобный способ заказов билетов на поезда. Система поможет эффективно распределять информацию в соответствие с запросами клиента, обеспечивать удобный и быстрый способ заказов билетов на поезда в сети Интернет.
Каким образом (и будет ли) ИС способствовать целям бизнеса?
Можно продать данную ИС Железнодорожным вокзалам, для увеличения прибыли в данной сфере
Требует ли разработка ИС технологии, которая до этого раньше не использовалась в организации?
Да, требует, для точного определения данных о станциях, маршрутах, времени отправления поездов, стоимости билетов на поезд.
Где будет размещена ИС? Кто является пользователем ИС?
Данная ИС будет размещена на сервере организации, так и в сети Интернет, для обеспечения доступа к ИС клиенту. Пользователями данной ИС являются: работники организации, пассажира.
Комплекс технических средств ИТ
Какие средства компьютерной техники необходимы для ИС?
Монитор, системный блок, клавиатура, мышь.
Какие средства коммуникационной техники необходимы для ИС?
Локальная, глобальная сети.
Какие средства организационной техники необходимы для ИС?
Средства составления и изготовления документов, средства обработки документов.
Какие средства оперативной полиграфии необходимы для ИС?
Опишите системное ПО ИТ.
Операционные системы Windows 7/8/8.1/10, Linux, браузер Интернета, офисные пакеты приложений Microsoft Office, Apache Openffice, антивирус Kaspersky Anti-Virus.
Ответы на контрольные вопросы:
Расскажите про процессы управления программными проектами.
Написание предложений по созданию ПО.
Планирование и составление графика работ проекта.
Оценивание стоимости проекта.
Контроль процессов выполнения работ.
Написание отчетов и представлений.
Расскажите про планирование проекта.
План, разработанный на начальном этапе проекта, рассматривается всеми его участниками как руководящий документ, выполнение которого должно привести к успешному завершению проекта. Этот первоначальный план должен максимально подробно описывать все этапы реализации проекта.
План проекта должен показать ресурсы, необходимые для реализации проекта, разделение работ на этапы и временной график выполнения этих этапов. Детализация планов проектов очень разнится в зависимости от типа разрабатываемого программного продукта и организации разработчика.
При планировании проекта разработки ПО определяются контрольные точки – вехи, отмечающие окончание определенного этапа работ. Для каждой вехи создается отчет, который предоставляется руководству проекта.
Представьте этапы процесса разработки спецификации.
Анализ требований (контрольная отметка – Пользовательские требования);
Проектная проработка (контрольная отметка – Проект архитектуры);
Специфицирование требований (контрольная отметка – Системные требования);
Что такое информационный процесс?
Что такое информационная система?
Что такое информационно-вычислительная работа?
Что такое информационно-вычислительная услуга?
Что представляет собой информационная система?
Информационная система представляет собой совокупность функциональной структуры, информационного, математического, технического, организационного и кадрового обеспечения, которые объединены в единую системы в целях сбора, хранения, обработки и выдачи необходимой информации для выполнения функций управления.
Какие информационные потоки обеспечивает ИС?
ИС обеспечивает информационные потоки:
Перечислите задачи информационных систем.
— гарантировать требуемое качество управления предприятием;
— повысить оперативность и эффективность взаимодействия между подразделениями;
— обеспечить управляемость качеством выпускаемой продукции;
— увеличить экономическую эффективность деятельности предприятия;
— создать систему статистического учета на предприятии;
— осуществлять прогноз развития предприятия;
— создать систему стратегического и оперативного планирования, систему прогнозирования.
Тут вы можете оставить комментарий к выбранному абзацу или сообщить об ошибке.
6 типичных проблем при внедрении решения по управлению проектами
Есть две ключевые причины, по которым компании, как правило, принимают решение о внедрении сервиса по управлению проектами. Первая заключается в том, что правильно подобранный сервис может решить как ряд текущих проблем, так и будущих, связанных с ростом компании. Вторая причина — повышение эффективности бизнес — процессов в целом. Разумеется, данные причины не являются взаимоисключающими — компании нередко внедряют решение для достижения всех целей сразу.
Когда организация принимает решение о внедрении, всегда наблюдаются схожие паттерны, например, ярко выраженный энтузиазм руководства на ранних этапах. Менеджмент ожидает быстрых результатов, улучшения показателей. Разумеется, все не так просто, и из-за ряда возникающих проблем все идет не по плану. В данной статье я разберу 6 типовых проблем, из-за которых решение по управлению проектами не приносит результатов. И, разумеется, предложу варианты решения для каждой из них.
Предлагаю начать с перечисления ключевых преимуществ для компании от использования решений по управлению проектами:
Руководство, как правило, ожидает, что компания получит некоторые (а лучше — все) из приведенных выше преимуществ, и решение начнет быстро приносить результаты. Но существует ряд факторов, которые могут привести к фиаско. В общем, речь всегда идет о двух вещах: отсутствие рабочего плана по управлению изменениями и невозможность построения и внедрения новых процессов с самого начала. Все проблемы, приведенные ниже, так или иначе относятся либо к первой, либо ко второй категории.
6 проблем
Проблема #1: Отсутствие онбординга или онбординг проведен неправильно
При внедрении решения, руководству приходится принимать во внимание множество факторов. Они включают в себя перенос в систему существующих на текущий момент бизнес-процессов, проведение обучения, распределение ролей (пользователь, админ) среди членов команды. Вся эта деятельность в совокупности называется “онбординг”.
Многие менеджеры недооценивают важность онбординга или вообще предпочитают его пропустить. Они думают, что решение “само приживется” и начнет приносить выгоду. У меня для вас плохие новости: этого не будет. Для того, чтобы решение начало приносить ценность, менеджмент должен инвестировать значительное количество времени на этапе внедрения. Незаконченный или плохо проведенный онбординг является серьезной проблемой. Часто оказывается, что сотрудники не готовы тратить время и совершать усилия на мероприятия, связанные с онбордингом: они не смотрят обучающие видео, не приходят на сессии по переносу бизнес процессов в новую систему (где, безусловно, требуется их экспертиза) или просто не разбираются даже с основным функционалом.
Решение:
Проблема #2: Отсутствие поддержки со стороны руководства
Принятие решения о внедрении инструмента по управлению проектами, является непростым. Как правило, в компаниях всегда есть несколько про-активных, технически подкованных сотрудников, которым только дай волю поэкспериментировать с новым инструментом. И это замечательно. Но тут есть и проблема: внедрение инструмента всегда приводит к полному перекраиванию игрового поля. Речь не идет о простом чеклисте с советами по повышению продуктивности. И энтузиазм пары сотрудников не будет достаточным для того, чтобы инструмент приносил организации ценность. Если руководство не обеспечит полную поддержку, как на стадии внедрения решения, так и в дальнейшем, оно столкнется с проблемой частичного (или полного) отсутствия результатов.
Решение:
Проблема #3: команда недостаточно хорошо обучена продукту
Удивительно, насколько много компаний недооценивают важность прохождения обучения по продукту на стадии его внедрения. В каждой компании есть 2 категории сотрудников: те, которые впитывают новые технологии, как губка, и те, для которых любое технически-сложное решение — большая проблема. Иногда сотрудники могут владеть основами использования системы по управлению проектами, но иметь проблемы с конкретным функционалом, который, как назло, имеет непосредственное отношение к их работе. То, что для какого-то конкретного сотрудника разобраться в новом продукте — вопрос тридцати минут, не значит, что это может быть стандартом для всех остальных. Помните, что все сотрудники разные.
Решение:
Проблема #4: сотрудники воспринимают решение как ненужную трату времени
Когда руководство принимает решение о внедрении продукта для управления проектами, оно обычно имеет четко сформулированные ожидания о ценности, которую продукт должен принести. Но данное утверждение не всегда работает для других сотрудников. Они могут думать, что новый инструмент — это очередная IT вундервафля, которой руководство будет заставлять пользоваться несколько месяцев, а потом все сойдет на нет. И это может стать серьезной проблемой.
Если вы откроете любую книгу по управлению изменениями, вы найдете следующую фразу в той или иной формулировке: “чтобы изменения произошли, люди должны хотеть измениться”. А сотрудники не захотят меняться, если в изменениях они не увидят для себя прямой выгоды. Даже подход “спускания” решений сверху вниз иногда может не сработать. Безусловно, процент сотрудников, которые пользуются решением каждый день вырастет, если руководство будет регулярно отслеживать это. Но одновременно это означает, что руководство неэффективно тратит время на навязывание использования решения, что, по сути противоречит самой концепции повышения эффективности процессов от решения (и, в частности, того, что решение призвано экономить время).
Решение:
Проблема #5: у команды уже есть негативные опыт использования другого решения в прошлом
Итак, команда уже пробовала аналогичный продукт, и попытка оказалась неудачной. Для этого могла быть масса причин. Но главный момент здесь заключается в том, что теперь у сотрудников будет негативное отношение к новому решению с самого начала. Ибо на прошлой решение, вероятно, было было потрачено немало времени, а результатов не последовало.
Компания, также, может решить внедрить продукт в неподходящий момент. Когда у сотрудников горит план продаж, надвигаются дедлайны, последнее, о чем они хотят думать, это “срочный перенос всех данных в новое супер-решение”.
Решение:
Проблема #6: В решении отсутствуют необходимые интеграции
Ряд популярных решений для управления проектами, представленных на рынке, среди своих преимуществ выделяют возможность стать центральным местом, в котором будет происходить все коммуникации по проектам. Но что делать, если в них отсутствуют нативные интеграции (к примеру, со Slack, Adobe и др.)? Просто предложить клиенту хороший изолированный продукт больше не достаточно. Наличие интеграций может стать ключевым фактором.
Даже если у решения есть нативные интеграции со всеми возможными продуктами и сервисами, важным остается наличие у решения открытого API. Это позволяет при необходимости разработать дополнительные интеграции.
Решение:
Внедрение решения по управлению проектами может оказать существенное влияние на эффективность бизнеса. Но позитивный эффект будет только в том случае, если компания готова потратить достаточно времени на этапе внедрения и после него. Мы надеемся, что приведенные советы помогут вам достичь желаемых результатов!
Метод выявления организационных проблем
Что такое проблема?
Организационная проблема существует при выполнении трех условий:
Во-первых, имеется устойчивое противоречие или разрыв между действительным и желаемым. В организациях подобные разрывы, свидетельствующие о наличии проблемы, возникают в оценках количественных и/или качественных показателей эффективности предприятия. Например, это могут быть расхождения между достигнутым и нормативным уровнем чистой прибыли, рентабельности инвестиций, объема продаж, текучести кадров, удовлетворенности клиентов, компетентности персонала и др.
Во-вторых, экспертам и руководителям организации не известны способы преодоления этого противоречия. Это означает, что истинные причины проблемы им достоверно не известны и требуют специальной диагностики. Например, удовлетворенность клиентов может упасть по разным причинам: из-за ухудшения качества продукции, падения уровня обслуживания, увеличения времени выполнения заказов, сужения ассортимента и др.
Более того, действительная причина проблемы может вообще не осознаваться руководителями, поскольку она находится за пределами привычного для них круга факторов. Скажем, это могут быть некие стереотипы мышления или отсутствие в организационной культуре некоторых ключевых ценностей, например, качества, доверия или ориентации на клиента.
В-третьих, в организации существует лицо или группа лиц, обеспокоенных этим противоречием. Другими словами, выявленное расхождение кого-то волнует, и это лицо предпринимает определенные умственные или практические действия для его преодоления.
Исходя из своего опыта, перечислю наиболее типичные проблемы российских предприятий:
Как же проводится общая организационная диагностика?
Для этого применяются специальные методы и процедуры. Наиболее информативный и мощный метод — диагностические интервью с руководителями и сотрудниками предприятия. В ходе интервью консультант с помощью проблемных и уточняющих вопросов управляет мышлением собеседника и ведет его от банальных жалоб (например, “мало платят!” или “теснота в производственных помещениях”) к определению истинных проблем организации и выявлению их причин.
Диагностическое интервью — это доверительная беседа, совместное размышление, интеллектуальный и эмоциональный диалог консультанта и руководителя, приводящий к осознанию не только самих проблем, но часто и методов их решения. Помимо интервью в арсенале консультантов, проводящих диагностику, имеются и другие методы получения диагностической информации: встречи по сбору данных, анализ управленческой документации, диагностическое наблюдение.
Диагностическая информация, собранная с помощью указанных методов, проходит далее несколько этапов переработки:
Как правильно формулировать проблемы организации?
Формулировки проблем — это утверждения, содержащие описание организационных явлений, которые оцениваются руководителями и сотрудниками как нежелательные для предприятия и/или имеющие негативное влияние на его функционирование и развитие. Например, уменьшаются рентабельность продаж и маржинальная прибыль компании; работники предприятия испытывают дефицит признания и поощрений со стороны руководителей; рабочие в цехе ориентированы на зарплату за работу, а не за результат; у большинства сотрудников предприятия преобладает прохладное и равнодушное отношение к труду.
Если известна причина того или иного явления, то она может быть включена в формулировку проблемы. Это позволяет существенно сократить общий перечень проблем и упростить анализ проблемного поля организации. Например:
Все выявленные организационные проблемы проходят тщательную экспертную оценку со стороны ключевых руководителей и сотрудников предприятия. В результате из общего списка исключаются формулировки проблем, которые, по мнению экспертов, излишне жесткие или просто-напросто не соответствуют действительности. При этом некоторые проблемы могут быть уточнены и выражены в более мягких формулировках.
Оставшиеся в списке проблемы подвергаются более тонкому логическому анализу. Предварительно для удобства и облегчения анализа все проблемы могут быть классифицированы и разделены на определенные группы. Например, подбор и текучесть кадров, маркетинг и продажи, организация производства, мотивация и стимулирование труда, стиль управления и др.
Конечный результат логического анализа — построение проблемного поля организации. Проблемное поле включает в себя не только формулировки выявленных проблем, но и причинно-следственные связи между ними.
Важность общей диагностики предприятия
Не секрет, что все организационные проблемы логически взаимосвязаны. Решение любой проблемы прямо или косвенно влияет на решение множества других проблем.
Цель диагностики состоит в том, чтобы на основе анализа проблемного поля обнаружить корневые проблемы, решение которых полностью устраняет или хотя бы ослабляет все остальные проблемы предприятия.
Стало быть, способы решения корневых проблем — это и есть оптимальные точки развития, в которых необходимо энергично и концентрировано воздействовать на организацию с целью ее “лечения” и преобразования.
В соответствии с терминологией теории ограничений корневые проблемы — это истинные причины организационных проблем, воспринимаемых руководителями как нежелательные явления. К нежелательным явлениям относятся явные проблемы организации, например, сокращение объема продаж или клиентской базы предприятия, уменьшение чистой прибыли, увеличение производственных потерь и др.
Факты возникновения таких проблем, как правило, очевидны или легко регистрируются с помощью систем бухгалтерского и управленческого учета. Однако, чтобы добраться до их истинных причин, необходимо выявить непосредственные причины нежелательных явлений, определить причины этих причин и далее, действуя таким же образом, провести полный и глубокий логический анализ всех проблем организации. В итоге все проблемное поле может быть разделено на три уровня.
В дальнейшем на основе анализа проблемного поля формулируются локальные и системные решения выявленных организационных проблем.
Вывод
Общая диагностика предприятия направлена на определение всего комплекса организационных проблем и выявление их причин. Это главное. Вместе с тем, диагностика позволяет получить ряд важных дополнительных результатов.
К ним относятся: новая ценная информация о состоянии организации; “размораживание” организации, снижение сопротивления переменам, запуск процесса организационных изменений; повышение управленческой квалификации руководителей, переосмысление собственного управленческого опыта, ошибок и достижений; практические рекомендации по развитию компании, детальный план организационных изменений.
Общая диагностика предприятия служит мощным инструментом организационного развития и формирует основу для принятия важных стратегических решений и преобразования организации.
Разработка описания и анализ информационной системы
Эффективное управление программным проектом. Идентификация точек зрения, получающих системные сервисы, и идентификация сервисов, соответствующих каждой точке зрения. Существующие типы проверок и методы аттестации требований. Программный интерфейс.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | лабораторная работа |
| Язык | русский |
| Дата добавления | 13.01.2015 |
| Размер файла | 193,8 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Лабораторная работа № 1 «Разработка описания и анализ информационной системы»
Описать и проанализировать информационную систему, распределить роли в группе разработчиков.
1. Описание информационной системы.
2. Проведение анализа осуществимости выполнения проекта.
3. Наличие заключения о возможности реализации проекта, содержащего рекомендации относительно разработки системы, базовые предложения по объёму требуемого бюджета, числу разработчиков, времени и требуемому программному обеспечению.
2. Можно ли реализовать систему, используя существующие на данный момент технологии и не выходя за пределы заданной стоимости?
3. Можно ли объединить систему с другими системами, которые уже эксплуатируются?
Критическим является вопрос, будет ли система соответствовать целям организации. Если система не соответствует этим целям, она не представляет никакой ценности для организации. В то же время многие организации разрабатывают системы, не соответствующие их целям, либо не совсем ясно понимая эти цели, либо под влиянием политических или общественных факторов.
Выполнение анализа осуществимости включает сбор и анализ информации о будущей системе и написание соответствующего отчета. Сначала следует определить, какая именно информация необходима, чтобы ответить на поставленные выше вопросы. Например, эту информацию можно получить, ответив на следующее:
1. Что произойдет с организацией, если система не будет введена в эксплуатацию?
2. Какие текущие проблемы существуют в организации и как новая система поможет их решить?
3. Каким образом система будет способствовать целям бизнеса?
4. Требует ли разработка системы технологии, которая до этого не использовалась в организации?
Далее необходимо определить источники информации. Это могут быть менеджеры отделов, где система будет использоваться, разработчики программного обеспечения, знакомые с типом будущей системы, технологи, конечные пользователи и т.д.
После обработки собранной информации готовится отчет по анализу осуществимости создания системы. В нем должны быть даны рекомендации относительно продолжения разработки системы. Могут быть предложены изменения бюджета и графика работ по созданию системы или предъявлены более высокие требования к системе.
Эффективное управление программным проектом напрямую зависит от правильного планирования работ, необходимых для его выполнения. План помогает руководителю предвидеть проблемы, которые могут возникнуть на каких-либо этапах создания ПО, и разработать превентивные меры для их предупреждения или решения. План, разработанный на начальном этапе проекта, рассматривается всеми его участниками как руководящий документ, выполнение которого должно привести к успешному завершению проекта. Этот первоначальный план должен максимально подробно описывать все этапы реализации проекта.
Процесс планирования начинается, исходя из описания системы, с определения проектных ограничений (временные ограничения, возможности наличного персонала, бюджетные ограничения и т.д.). Эти ограничения должны определяться параллельно с оцениванием проектных параметров, таких как структура и размер проекта, а также распределением функций среди исполнителей. Затем определяются этапы разработки и то, какие результаты документация, прототипы, подсистемы или версии программного продукта) должны быть получены по окончании этих этапов. Далее начинается циклическая часть планирования. Сначала разрабатывается график работ по выполнению проекта или дается разрешение на продолжение использования ранее созданного графика. После этого проводится контроль выполнения работ и отмечаются расхождения между реальным и плановым ходом работ.
Далее, по мере поступления новой информации о ходе выполнения проекта, возможен пересмотр первоначальных оценок параметров проекта. Это, в свою очередь, может привести к изменению графика работ. Если в результате этих изменений нарушаются сроки завершения проекта, должны быть пересмотрены (и согласованы с заказчиком ПО) проектные ограничения.
Конечно, большинство руководителей проектов не думают, что реализация их проектов пройдет гладко, без всяких проблем. Желательно описать возможные проблемы еще до того, как они проявят себя в ходе выполнения проекта. Поэтому лучше составлять «пессимистические» графики работ, чем «оптимистические». Но, конечно, невозможно построить план, учитывающий все, в том числе случайные, проблемы и задержки выполнения проекта, поэтому и возникает необходимость периодического пересмотра проектных ограничений и этапов создания программного продукта.
План проекта должен четко показать ресурсы, необходимые для реализации проекта, разделение работ на этапы и временной график выполнения этих этапов. В некоторых организациях план проекта составляется как единый документ, содержащий все виды планов, описанных выше. В других случаях план проекта описывает только технологический процесс создания ПО. В таком плане обязательно присутствуют ссылки на планы других видов, но они разрабатываются отдельно от плана проекта.
Детализация планов проектов очень разнится в зависимости от типа разрабатываемого программного продукта и организации-разработчика. Но в любом случае большинство планов содержат следующие разделы.
1. Введение. Краткое описание целей проекта и проектных ограничений (бюджетных, временных и т.д.), которые важны для управления проектом.
2. Организация выполнения проекта. Описание способа подбора команды разработчиков и распределение обязанностей между членами команды.
3. Анализ рисков. Описание возможных проектных рисков, вероятности их проявления и стратегий, направленных на их уменьшение.
4. Аппаратные и программные ресурсы, необходимые для реализации проекта. Перечень аппаратных средств и программного обеспечения, необходимого для разработки программного продукта. Если аппаратные средства требуется закупать, приводится их стоимость совместно с графиком закупки и поставки.
5. Разбиение работ на этапы. Процесс реализации проекта разбивается на отдельные процессы, определяются этапы выполнения проекта, приводится описание результатов («выходов») каждого этапа и контрольные отметки.
6. График работ. В этом графике отображаются зависимости между отдельными процессами (этапами) разработки ПО, оценки времени их выполнения и распределение членов команды разработчиков по отдельным этапам.
7. Механизмы мониторинга и контроля за ходом выполнения проекта. Описываются предоставляемые руководителем отчеты о ходе выполнения работ, сроки их предоставления, а также механизмы мониторинга всего проекта.
План должен регулярно пересматриваться в процессе реализации проекта. Одни части плана, например график работ, изменяются часто, другие более стабильны. Для внесения изменений в план требуется специальная организация документопотока, позволяющая отслеживать эти изменения.
Роли в группе по разработке ПО:
Эффективное управление программным проектом напрямую зависит от правильного планирования работ, необходимых для его выполнения. План помогает руководителю предвидеть проблемы, которые могут возникнуть на каких-либо этапах создания ПО, и разработать превентивные меры для их предупреждения или решения. План, разработанный на начальном этапе проекта, рассматривается всеми его участниками как руководящий документ, выполнение которого должно привести к успешному завершению проекта.
Процесс создания профессионального ПО всегда является субъектом бюджетной политики организации, где оно разрабатывается, и имеет временные ограничения. Работа руководителя программного проекта заключается в том, чтобы гарантировать выполнение этих бюджетных и временных ограничений с учетом бизнес-целей организации относительно разрабатываемого ПО.
Руководители проектов призваны спланировать все этапы разработки программного продукта. Они также должны контролировать ход выполнения работ и соблюдения всех требуемых стандартов. Постоянный контроль за ходом выполнения работ необходим для того, чтобы процесс разработки не выходил за временные и бюджетные ограничения.
Лабораторная работа № 2 «Разработка требований к информационной системе»
Составить и проанализировать требования к информационной системе, оформить техническое задание на разработку программного обеспечения
1. Идентификация точек зрения, получающих системные сервисы, и идентификация сервисов, соответствующих каждой точке зрения.
3. Документирование опорных точек зрения, которое заключается в точном описании идентифицированных точек зрения и сервисов.
4. Отображение системы точек зрения, которая показывает системные объекты, определенные на основе информации, заключенной в опорных точках зрения.
Пример. Рассмотрим использование метода VORD на первых трех шагах анализа требований для системы системы поддержки заказа и учета товаров в бакалейной лавке. В бакалейной лавке для каждого товара фиксируется место хранения (определенная полка), количество товара и его поставщик. Система поддержки заказа и учета товаров должна обеспечивать добавление информации о новом товаре, изменение или удаление информации об имеющемся товаре, хранение (добавление, изменение и удаление) информации о поставщиках, включающей в себя название фирмы, ее адрес и телефон. При помощи системы составляются заказы поставщикам. Каждый заказ может содержать несколько позиций, в каждой позиции указываются наименование товара и его количество в заказе. Система по требованию пользователя формирует и выдает на печать следующую справочную информацию:
· список всех товаров;
· список товаров, имеющихся в наличии;
· список товаров, количество которых необходимо пополнить;
· список товаров, поставляемых данным поставщиком.
Следующей стадией процесса формирования требований будет идентификация опорных точек зрения (на рис. 4 показаны в виде темных круговых областей) и сервисов (показаны в виде затененных областей). Сервисы должны соответствовать опорным точкам зрения. Но могут быть сервисы, которые не поставлены им в соответствие. Это означает, что на начальном этапе «мозговой атаки» некоторые опорные точки зрения не были идентифицированы.
Рис. 4 Диаграмма идентификации точек зрения
В таблице 1 показано распределение сервисов для некоторых идентифицированных на рис. 4.
