- •Разработка и стандартизация программных систем
- •1. Три типа жизненных циклов программных систем.
- •Водопадная (каскадная, последовательная) модель
- •Итерационная модель
- •Спиральная модель
- •3. Стандарт iso серии 9000 при разработке программных систем.
- •Iso 9000 — серия международных стандартов, описывающих требования к системе менеджмента качества организаций и предприятий.
- •4. Стандарты Единой системы программной документации (еспд)
- •Классификация:
- •5. Стандарты рф (гост р) на документирование пс
- •6. Организация группы проекта при разработке программных систем.
- •7. Три способа определения требований к программной системе.
- •8. Спецификация требований к программной системе.
- •9. Методы контроля спецификации требований.
- •10. Спецификация качества программных систем.
- •11. Функциональная спецификация программных систем.
- •12. Архитектура программных систем
- •13. Основные классы архитектур программных систем.
- •14. Основные модели при разработке программных систем.
- •(См. Вопрос 1!)
- •15. Принципы объектно-ориентированного анализа и проектирования пс
- •16. Принципы компонентной архитектуры информационных систем.
- •17. Стандарты семейства idef
- •18. Принципы построения модели idef0
- •19. Принципы разработки моделей as-is и то-ве
- •20. Диаграммы в стандарте idef0
- •21. Понятие работы в стандарте idef0
- •22. Описание взаимодействия работ в стандарте idef0
- •23. Типы связей работ в стандарте idef0
- •24. Стандарт idef1x
- •26. Диаграммы потоков данных.
- •27. Архитектурные виды программной системы.
- •28. Фазы, итерации и циклы разработки программных систем - руп.
- •29. Рабочие процессы создания программных систем - руп.
- •30. Основные артефакты при разработке программных систем.
- •31. Концепция языка uml
- •32. Язык uml как система визуализации, специфицирования, конструирования, документирования
- •33. Понятия модели и системы в языке uml
- •34. Принципы моделирования системной архитектуры в языке uml.
- •35. Принципы представления системы в языке uml.
- •36. Понятие сущностей в языке uml
- •37. Структурные сущности предметной области.
- •38. Отношения в языке uml
- •39. Диаграммы в языке uml
- •40. Правила языка uml.
- •41. Общие механизмы языка uml
- •42. Прецедент как спецификация поведения программных систем.
- •43. Организация прецедентов в языке uml.
- •44. Приемы анализа прецедентов в языке uml
- •45. Диаграммы прецедентов.
- •46. Моделирование требований к системе с помощью диаграмм прецедентов.
- •47. Критерии сравнения инструментальных систем разработки программных систем.
- •48. Технико-экономические показатели разработки программных средств
- •49. Сертификация программных средств
- •50. R-технология программирования
6. Организация группы проекта при разработке программных систем.
Для разработки ПО организуется некоторый коллектив. Такую рабочую группу называют группой проекта. В состав группы обычно входят следующие специалисты:
· руководитель проекта - координирует все действия, организует внешнее и внутреннее взаимодействия группы проекта, обеспечивает соблюдение сроков разработки и качество разрабатываемого ПО и его соответствие требованиям заказчика, несет полную ответственность за результат работ по проекту;
· системный аналитик - анализирует требования к системе, разрабатывает концепцию и логику работы системы, составляет технические задания или подобные документы, несет ответственность за соответствие предлагаемых решений требованиям заказчика;
· разработчики - реализуют принятые технические задания, отвечают за качество и сроки разрабатываемого кода, за его соответствие техническим заданиям;
· дизайнер - участвует в разработке концепции системы, разрабатывает ее пользовательский интерфейс и принимает участие в его реализации, несет ответственность за соблюдение фирменного стиля и требований к реализации пользовательского интерфейса;
· тестер - разрабатывает программу тестирования, осуществляет ее и несет ответственность за полноту тестирования готовых модулей и системы в целом;
· технический писатель - разрабатывает документацию на проект, несет ответственность за полноту и правильность описания.
Дизайнер, тестер и технический писатель могут в группу постоянно не входить, а работать над несколькими проектами и привлекаться к работе по мере необходимости. В подразделение по разработке ПО, состоящее из нескольких проектных групп, может входить технолог, который разрабатывает, внедряет и поддерживает технологию производства программных продуктов. Для сложных проектов, связанных с активным применением сетевых решений, Internet технологий и т. д. в группу проекта может подключаться специалист по использованию сетей. Кроме непосредственной команды разработчиков проекта, над проектом могут работать и другие специалисты компании: менеджеры, маркетологи...
7. Три способа определения требований к программной системе.
Определение требования к ПС являются исходным документом разработки ПС - заданием, выражающем в абстрактной форме потребности пользователя. Они в общих чертах определяют замысел ПС, характеризуют условия его использования.
Исходным документом для разработки внешнего описания ПС являются определение требований к ПС.
Определение требований представляет собой смесь фрагментов на естественном языке, различных таблиц и диаграмм. Такая смесь, должна быть понятной пользователю, не знающего специальных программистских обозначений. Обычно в определении требований не содержится формализованных фрагментов, кроме случаев достаточно для этого подготовленных пользователей (например, математически) - формализация этих требований составляет содержание дальнейшей работы коллектива разработчиков.
Известны три способа определения требований к ПС:
управляемый пользователем,
контролируемый пользователем,
независимый от пользователя.
В управляемой пользователем разработке определения требований к ПС определяются заказчиком, представляющим организацию пользователей. Это происходит обычно в тех случаях, когда организация пользователей (заказчик) заключает договор на разработку требуемого ПС с коллективом разработчиков и требования к ПС являются частью этого договора.
В контролируемой пользователем разработке требования к ПС формулируются разработчиком при участии представителя пользователей. Роль пользователя в этом случае сводится к информированию разработчика о своих потребностях в ПС и контролю за тем, чтобы формулируемые требования действительно выражали его потребности в ПС. В конечном счете разработанные требования, как правило, утверждаются представителем пользователя.
В независимой от пользователя разработке требования к ПС определяются без какого-либо участия пользователя (на полную ответственность разработчика). Это происходит обычно тогда, когда разработчик решает создать ПС широкого применения в расчете на то, разработанное им ПС найдет спрос на рынке программных средств.
С точки зрения обеспечения надежности ПС наиболее предпочтительным является контролируемая пользователем разработка.