Auth (Authentication/Authorization) Component - This Component Shall Consist of A Set of

The document proposes developing a task management and reporting web application for a client that is integrated with Google OAuth and Calendar APIs. It will use a microservices architecture with components for authentication, task management, and reporting. The frontend will be an Angular SPA and the backend microservices will use ASP.NET Core and PostgreSQL. Development will follow an agile methodology over 5 iterations within 6 weeks.

Uploaded by

miki tesfay

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as DOCX, PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

38 views3 pages

Auth (Authentication/Authorization) Component - This Component Shall Consist of A Set of

Uploaded by

miki tesfay

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as DOCX, PDF, TXT or read online on Scribd

You are on page 1/ 3

Introduction

From our previous discussions, we at Infinitech Computing Solutions PLC, hereafter referred to
as ICSP, have formed a broad understanding of the needs of IE Networking Solutions, hereafter
referred to as the client, which are detailed hereunder:
⦁ Develop a simple task-management and reporting web application
⦁ Integrate Google OAuth for Single Sign-On (SSO)
⦁ Integrate the web application with Google Calendar to manage events and date-related
attributes (due dates, task durations ...)
⦁ Implement a Role-Based Security model for various application resources
⦁ Ensure high-availability and scalability for the proposed web application
⦁ Design various Unit, Integration and End-to-End (E2E) tests for each component

Objectives
ICSP is able and willing to provide the client with a simple web application to manage
daily/weekly planning and reporting, integrated with Google OAuth for Authentication and
Google Calendar API to manage daily/weekly plans.
We propose to adopt a microservice approach, whereby, we'll divide the system into loosely-
coupled, yet highly cohesive components, developed primarily using ASP.NET Core (with C#),
and expose each functionality as a REST API endpoint, which will be language/platform
agnostic. We'll develop the front end components as Single Page Applications (SPAs), using
Angular 2 with HTML5 and CSS. The backend storage shall be implemented in PostgreSQL
and EventStore. These will enable the web application to run on both Windows and Linux
environments. In the future, it will also be possible to evolve the front-end into a Progressive
Web Application, that can make use of Service Workers and client-side caching of resources, to
deliver a native-application-like experience for users.
The proposed solution shall comprise of the following components, detailed hereunder,
complete with their respective proposed platforms, languages and frameworks.
1. Auth (Authentication/Authorization) component - This component shall consist of a set of
microservices that'll use Google OAuth 2 to authenticate team members, and a centralized
Roles and Permissions repository to assign authenticated users to particular Roles and/or
Permissions. The Auth component microservices shall be developed using ASP.NET Core and
ASP.NET Core Identity with Postgres as a backend.

* Note that Users will have to allow the application OAuth Access to manage their Google
Calendar.
2. Task Management component - This component shall expose core microservices, i.e REST
endpoints to manage Boards, Lists and Tasks. We propose a Kanban-like tasks management
dashboard, comprising of Boards (to group related tasks by project), Columns (eg. Backlog, To-
Do, Doing, Done ...) and Cards (similar to Sticky Notes) to manage tasks and task lifetimes. The
dashboard will also have an intuitive UI that'll make it extremely simple to
⦁ Assign one or more team-members to a task
⦁ Link external resources (Google Docs, Spreadsheets, Attachments, URIs...) to a task
⦁ Follow up on the entire Audit Log of a task (Creation, Assignment and even deletion)
The Front-end will be developed as a SPA, and the microservices using ASP.NET Core Web
API, and it will use PostgreSQL for back-end storage with EventStore for event-sourcing (audit).
3. Reporting Component - We propose a number of executive reports to aid the client in
decision making, including, but not limited to, Burn-down charts, Stale tasks (tasks taking too
long to be completed), Tasks by team-member ....
Methodology
Instead of following the traditional software development methodology of "requirements analysis
-> design -> implementation", we propose to adopt a more pragmatic, iterative approach (the
Agile Methodology), whereby, we provide continuous delivery of the proposed systems
throughout consecutive iterations and weekly sprints. Therefore, the client will have insights to a
working product starting from the initial week of development. This will benefit both parties, as it
incorporates user-stories and feedbacks to the end product.

Technologies
Below is a complete list of proposed languages, frameworks, tools and technologies with their
respective components
HTML5, CSS, Bootstrap 3, Angular 2 - Front-end (UI) components
C#, .NET Core, ASP.NET Core Web APIs - Microservices
PostgreSQL, EventStore - Back-end Storage and Audit Logging
AWS/ Microsoft Azure/Heroku - Cloud deployment (for development and staging environments)
Git, GitHub - Source Code Repository
Client's Linux Server - Production deployment (we'll need to discuss access and configuration to
this server)
AppVeyor - Continuous Integration (CI), Build and Deployment to Dev, Staging and Production
environments
RayGun - Error and Crash Reporting

Timescale and Project Plan

Based on the aforementioned processes, ICSP proposes the following tentative time-frame for
delivering the requested service.
1. Iteration 0 - Project specifications & mock-up design sign-off and initial set-up (Issue
Tracking, Source Code Repository, Continuous Integration, Deployment Configuration ...) - 5
man days
2. Iteration 1 - Auth Component and Google API integration - 5 days
3. Iteration 2 - Core Tasks Management Component (Part I)- 5 days
4. Iteration 3 - Core Tasks Management Component (Part II)- 5 days
5. Iteration 4 - Reporting Component- 5 days
6. Iteration 5 - Production Deployment, Bug-fixing .. - 5 days
* Each iteration shall span 4 working days and 1 User-Acceptance-Testing (UAT) day. We'll also
configure 3 environments (Development, Staging and Production), whereby, features can be
tested on Development (automatically deployed from the latest development branch), Staging
(automatically deployed from master branch, i.e. changes that have passed UAT) and
Production (Final deployment)
** We anticipate additional reporting needs to arise even after the final delivery of the product.
Therefore, we hope to design & implement additional custom reports based on the needs of the
client.
*** We are also confident that the proposed timescale will be realized as (some) overlaps can
be arranged. In addition, we intend to utilize code from past projects.

Man Hours (Days)

Front-end Developer - 6 weeks x 5 days/week = 30 man days (240 man hours)
Lead Developer (Full-stack experience) - 6 weeks x 5 days/week = 30 man days (240 man
hours)
* The Lead Developer will also act as a primary contact point between ICSP and the client.