Эксплуатация ис

1. Общая настройка работы программы. Учетная политика предприятия.

2. Начало ведения учета. Ввод данных до текущей даты.

3. Учет кассовых и банковских операций в программе 1С: Предприятие.

4. Учет расчетов с контрагентами. Расчеты с покупателями и заказчиками, поставщиками и подрядчиками.

5. Учет материалов, товаров, готовой продукции.

6. Учет материально-производственных запасов и готовой продукции.

7. Инвентаризация товарно-материальных ценностей.

8. Учет основных средств, нематериальных активов в программе 1С: предприятие.

9. Учет кадров на предприятии. Расчеты с работниками по оплате труда.

10. Учет операций с подотчетности лицами.

11. Формирование финансовых результатов. Бухгалтерская и налоговая отчетность.

12. Формирование книги Покупок и Книги продаж за отчетный период

13. Формирование регламентных отчетов предприятия

14. Экспортирование и импортирование данных бухгалтерского учета. Взаимодействие программ

15. Типичные ошибки при работе с программой «1С: Предприятие»

16. Взаимодействие программ профессиональной деятельности бухгалтера.

Методы и средства проектирования ис

1. Основные термины индустрии ИС 2. Процесс разработки ИС 3. Анализ требований. 4. Принципы и методологии структурного анализа. 5. Построение модели деятельности с использованием IDEF0. 6. Словари данных. Спецификации данных в функциональных моделях. 7. Спецификации процессов. Методология IDEF3 8. Моделирование данных в методологии IDEF1x. 9. Основные принципы объектного подхода к проектированию ИС. Язык UML. 10. Проектирование функциональности ПО. UML Use-Case. 11. Проектирование внутренней структуры приложений. UML Class Diagram. 12. Проектирование динамики приложений. UML Sequence Diagram и UML Collaboration Diagram. 13. Управление требованиями к ИС. Методы, средства. 14. Кодогенерация в CASE средствах. Генерация клиентской части в Rational Rose. Генерация серверной части в ERWin. 15. Функциональное тестирование. Методы, средства. Связь функциональных тестов с требованиями к ПО. 16. Нагрузочное тестирование. Методы, средства. Управление набором тестов. 17. Ресурсы, риски и графики выполнения программных проектов. 18. Техника управления программными проектами на базе методологии функциональных точек. 19. Методы организации бригад разработчиков. 20. Методы взаимодействия в коллективах разработчиков.

11 Центральное место в ООАП занимает разработка логической модели системы в виде диаграммы классов. Нотация классов в языке UML проста и интуитивно понятна всем, кто когда-либо имел опыт работы с CASE-инструментариями. Схожая нотация применяется и для объектов – экземпляров класса, с тем различием, что к имени класса добавляется имя объекта и вся надпись подчеркивается. Нотация UML предоставляет широкие возможности для отображения дополнительной информации (абстрактные операции и классы, стереотипы, общие и частные методы, детализированные интерфейсы, параметризованные классы). При этом возможно использование графических изображений для ассоциаций и их специфических свойств, таких как отношение агрегации, когда составными частями класса могут выступать другие классы. Диаграмма классов (class diagram) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывает их внутреннюю структуру и типы отношений. На данной диаграмме не указывается информация о временных аспектах функционирования системы. С этой точки зрения диаграмма классов является дальнейшим развитием концептуальной модели проектируемой системы. Диаграмма классов представляет собой некоторый граф, вершинами которого являются элементы типа «классификатор», которые связаны различными типами структурных отношений. Следует заметить, что диаграмма классов может также содержать интерфейсы, пакеты, отношения и даже отдельные экземпляры, такие как объекты и связи. Когда говорят о данной диаграмме, имеют в виду статическую структурную модель проектируемой системы. Поэтому диаграмму классов принято считать графическим представленном таких структурных взаимосвязей логической модели системы, которые не зависят или инвариантны от времени. Диаграмма классов состоит из множества элементов, которые в совокупности отражают декларативные знания о предметной области. Эти знания интерпретируются в базовых понятиях языка UML, таких как классы, интерфейсы и отношения между ними и их составляющими компонентами. При этом отдельные компоненты этой диаграммы могут образовывать пакеты для представления более общей модели системы. Если диаграмма классов является частью некоторого пакета, то ее компоненты должны соответствовать элементам этого пакета, включая возможные ссылки на элементы из других пакетов. В общем случае пакет статической структурной модели может быть представлен в виде одной или нескольких диаграмм классов. Декомпозиция некоторого представления на отдельные диаграммы выполняется с целью удобства и графической визуализации структурных взаимосвязей предметной области. При этом компоненты диаграммы соответствуют элементам статической семантической модели. Модель системы, в свою очередь, должна быть согласована с внутренней структурой классов, которая описывается на языке UML.

12 UML Sequence Diagram- В языке UML взаимодействие элементов рассматривается в информационном аспекте их коммуникации, т. е. взаимодействующие объекты обмениваются между собой некоторой информацией. При этом информация принимает форму законченных сообщений. Другими словами, хотя сообщение и имеет информационное содержание, оно приобретает дополнительное свойство оказывать направленное влияние на своего получателя. Это полностью согласуется с принципами ООАП, когда любые виды информационного взаимодействия между элементами системы должны быть сведены к отправке и приему сообщений между ними. Для моделирования взаимодействия объектов в языке UML используются соответствующие диаграммы взаимодействия. Говоря об этих диаграммах, имеют в виду два аспекта взаимодействия. Во-первых, взаимодействия объектов можно рассматривать во времени, и тогда для представления временных особенностей передачи и приема сообщений между объектами используется диаграмма последовательности. Этот вид канонических диаграмм является предметом изучения настоящей главы. Ранее, при изучении диаграмм состояния и деятельности, было отмечено одно немаловажное обстоятельство. Хотя рассмотренные диаграммы и используются для спецификации динамики поведения систем, время в явном виде в них не присутствует. Однако временной аспект поведения может иметь существенное значение при моделировании синхронных процессов, описывающих взаимодействия объектов. Именно для этой цели в языке UML используются диаграммы последовательности. Во-вторых, можно рассматривать структурные особенности взаимодействия объектов. Для представления структурных особенностей передачи и приема сообщений между объектами используется диаграмма кооперации.

UML Collaboration Diagram.-Прежде всего, на диаграмме кооперации в виде прямоугольников изображаются участвующие во взаимодействии объекты, содержащие имя объекта, его класс и, возможно, значения атрибутов. Далее, как и на диаграмме классов, указываются ассоциации между объектами в виде различных соединительных линий. При этом можно явно указать имена ассоциации и ролей, которые играют объекты в данной ассоциации. Дополнительно могут быть изображены динамические связи – потоки сообщений. Они представляются также в виде соединительных линий между объектами, над которыми располагается стрелка с указанием направления, имени сообщения и порядкового номера в общей последовательности инициализации сообщений. В отличие от диаграммы последовательности, на диаграмме кооперации изображаются только отношения между объектами, играющими определенные роли во взаимодействии. С другой стороны, на этой диаграмме не указывается время в виде отдельного измерения. Поэтому последовательность взаимодействий и параллельных потоков может быть определена с помощью порядковых номеров. Следовательно, если необходимо явно специфицировать взаимосвязи между объектами в реальном времени, лучше это делать на диаграмме последовательности. Поведение системы может описываться на уровне отдельных объектов, которые обмениваются между собой сообщениями, чтобы достичь нужной цели или реализовать некоторый сервис. С точки зрения аналитика или конструктора важно представить в проекте системы структурные связи отдельных объектов между собой. Такое статическое представление структуры системы как совокупности взаимодействующих объектов и обеспечивает диаграмма кооперации. Таким образом, с помощью диаграммы кооперации можно описать полный контекст взаимодействий как своеобразный временной «среза» совокупности объектов, взаимодействующих между собой для выполнения определенной задачи или бизнес-цели программной системы.

17. Существует три категории стратегий управления рисками:

1. Стратегии предотвращения рисков. Согласно этим стратегиям следует проводить мероприятия, снижающие вероятность проявления рисков. Примером может служить стратегия исключения потенциально дефектных компонентов.

2. Минимизационные стратегии. Направлены на уменьшение возможного ущерба от рисков. Примером служит стратегия уменьшения ущерба от болезни членов команды разработчиков.

3. Планирование "аварийных" ситуаций. Согласно этим стратегиям необходимо иметь план мероприятий, которые следует выполнить в случае проявления рисковой си­туации. В табл. 4.7 это стратегия поведения при возникновении финансовых про­блем у организации разработчика.

Мониторинг рисков

Тип риска	Признаки
Технологические риски	Задержки в поставке оборудования или программных средств поддержки процесса создания ПО, многочисленные документи­рованные технологические проблемы
Риски, связанные с персоналом	Низкое моральное состояние персонала, натянутые отношения между членами команды разработчиков, низкое качество выпол­ненной работы
Организационные риски	Разговоры среди персонала о пассивности и недостаточной компетентности высшего руководства организации
Инструментальные риски	Нежелание разработчиков использовать программные средства поддержки, неодобрительные отзывы о CASE-средствах, запросы на более мощные инструментальные средства
Риски, связанные с системными требованиями	Необходимость пересмотра многих системных требований, недовольство заказчика ПО
Риски оценивания	Изменения графика работ, многочисленные отчеты о нарушении графика работ