Management system for The Stute

1. Management system for The Stute The system will manage the day to day operations and website of Stevens’ student newspaper, The Stute.

2. Technologies • ASP.NET with C# • Chosen for web controls • AJAX and Javascript • Some built in functionality with .NET, some custom created • Entity Framework with LINQ

3. Requirements Elicitation • Met with customer to review goals and expectations of the product • Priorities discussed and assigned to system features • Approved requirements are the foundation for the first development iteration • Requirements are broken down and sorted into logical organizations for easy access and clarification

4. User Requirements Specification • Documents the purpose for which a system is required and what the user is expecting from the system • Most critical and most often botched document • Important that URS is as detailed and specified as possible • Any changes to URS must be approved by Project Manager, Project Architect, and customer

5. Functional Specification • Describes the characteristics of the product’s intended features • Details how the user will interact with the system and how the system will operate • Helps to streamline the development process by attempting to eliminate “guesswork”

6. Requirements Traceability Matrix • Associates requirements with the work products that satisfy them. • Helps to ensure that a requirement is not orphaned through the URS -> FS -> DS -> TS path. • Updates are made with any change to URS, FS, or DS.

7. Database Schema • Developed with data integrity in mind. • Ignored object model, which is created by the Entity Data Model. • Collection hierarchy • Issues, Assignments, Categories, etc. are all subtypes of Collection. • Collection is responsible for managing hierarchical data in a many-to-many fashion.

9. Entity Data Model • ADO.NET Entity Framework wraps the database (“logical level”). • Code generation engine builds rudimentary object model (“conceptual level”). • We add additional functionality to the code generated objects (“business logic level”). • Database interaction occurs using LINQ and Entity SQL to the conceptual level or function calls directly to the business logic.

11. Security Architecture • Role-Based • Each user has a role • A specific role is needed to perform any given task • A role is a set of policies (permissions) • Area-Specific Policies • Global • Area of effect is across entire system • Local • Area of effect is specific to a collection • Allows flexibility with arbitrary, confined power

12. Security Architecture • Local Policies affect Sub-Collections • Power in a certain collection implies power in all its child collections • Hierarchical Roles • A role can inherit from several others • Gains any policies parents have • Can also have non-inherited policies • A change to a parent cascades • Very easy for role creation and management

13. Security Architecture

14. Security Architecture • Things Under Construction • Integration with Stevens’ LDAP server • Log into system with Stevens credentials • HTTPS/SSL • Secure session while logged into system

15. Project Management • Trac • System to track development of the system and provide a project notebook. • Subversion • Used for versioning of source code and project documents. • Mailing List

16. Test Specifications and Plans • Present a detailed summary of what scenarios will be tested and how they will be tested for a given feature • All Test Specifications for a given system area will be integrated into the Test Plan for that area.

17. Future Development • Complete Drag & Drop AJAX interface for creating and editing Collections, Issues, Assignments and Categories. • WebDAV support to allow Collections and assets to be accessed as if it were a file system.