Group 7: Final Report - SoftwareEngineeringGroupProject/SEGP1B-Cluster3 GitHub Wiki

Introduction 

Engagement

In a broad nature, this project is attempting to increase Engagement with industry for the University of Adelaide Bachelor of Engineering (Software) degree. It specifically aims to improve Engagement between the Course Administrators and Industry by increasing visibility of the course and improving interaction between both parties. Group 7's particular focus is on the management of prospective projects between the parties.

Background

Currently a large amount of time is being spent on locating viable Bachelor of Engineering (Software) fourth year group projects. It is both difficult to initially locate interested industry representatives, due to low visibility of the program. Once a communication channel has been opened with a prospective industry partner, much time is spent obtaining the initial project idea and further time is spent communicating between the industry partner and the course coordinator to determine whether the project is viable. Projects must be achievable for three students to undertake in the allotted time or approximately 26 weeks. It has been estimated that the process of project idea refinement and validation currently takes on average 40 hours per project. Currently all the information gathered about prospective projects is not easily sortable and locatable (hidden away in coordinator email archives etc.). This can mean that some information may not be communicated about the project when assigning a project to a team of students.

Specification

High Level Functional Aims

To build an industry partner accessible system that helps the course coordinator to obtain Industry projects from the community passively (i.e. without having to proactively search).
To manage all aspects of the project starting from the first point of contact with the initial idea through the approval stages, until the point where the project is assigned to a team of students.
To reduce the overall time taken to source and approve Industry projects.
To consolidate all gathered information about prospective projects in single place, allowing for better management and review.
To provide students with a rough set of initial requirements to begin project work immediately.
To promote use with the help of push notifications.

High Level Non Functional Aims

Security - Prevent against unauthorised usage or attack
Authentication - Prevent unauthorised access to sensitive material
The system must be fault tolerant - Recover from errors in outside components

Detailed Specification

The Prospective Project Management System essentially aims to 'show off' the Bachelor of Engineering (Software) degree by showcasing projects completed in past years. The hope is this will cause industry representatives to submit project ideas via the adjoined system, meaning the burden of hunting for 4th year projects is diminished.

Design 

####Domain Analysis: Based on requirements gathered from our main client (Kevin), the developed system will provide services for two main types of users: Project course coordinators and industry partners. These users will play active roles in the system and main actors in our use case model. Apart from coordinator and industry partner users, our group work has to concern the role of students as an inactive part of the system who will have some passive interactions with coordinator users – though in other group's work of our cluster, students would play the main role in the services they developed.

After identifying the main roles playing in the system, the interactions between these three roles and the application are then specified via a detailed set of use cases as listed below:

Use case listings

Industry Partner

A prospective industry partner plays the initial steps in the main usage workflow for the PPMS system. The industry partner will navigate to the application via either a link of the current University of Adelaide Computer Science homepage or via a link in an email send by the current Course Coordinator. As the current project gathering process primarily utilises industry existing contacts, emailing these contacts would maintain the benefit of targeted delivery. Once the industry user has navigated to the system, they would (optionally) browse the past projects that previous fourth year Software Engineering students have completed. This should allow them to see the quality of work completed in the past meaning they will be more likely to want to submit a project. The user would then Register for an account using the Register Button, which allows them to make and account. After they have registered for an account, the will then be able to submit a project proposal. A number of fields would be presented to the user according to the fields required by course coordinators to verify a project idea is suitable for three fourth year SEGP students. However only project name and description will be mandatory as some fields will not apply in all cases, and the system should not overwhelm the user by asking too much. Once a number of these fields have been entered and the project has been submitted it will appear in the users 'My Projects' section. From here they can manage different aspects of the project idea submission.

Functions

SIGNING UP

Navigate to page.
Click on the register link.
Enter user details and his/her company details ( The system will notify any invalid data input from user and allow him/her to re-enter).
User receives a message from system notifying him/her of the successfully created account.

LOGGING IN

Navigate to page.
Click on the login link.
Enter user-name or email and user password ( The system will notify any invalid data input or or incorrect from user and allow him/her to re-enter).
User logging in successfully and being redirected to home page where user can choose either going to his/her profile page, personal dashboard or submission page.

Alternative scenario: User forgetting their password.

User clicks on “forgot password” link on login page, system will direct user to another prompt panel asking him/her for the email information.
User enters his/her email, and is notified about the reset password email.
User goes to their mail box, clicking on the link provided by the email sent by our system.
After reset password page pops up, user can enter their new password.

SUBMITTING A PROJECT

Navigate to page with logged-in status.
Link to Submit Project page.
Enter detail information about the project, attaching a description file if any.

Alternative scenario: User goes to submit page without being logged in or having ann account. System will notify user and ask him/her to perform either singing up or logging in to continue which use cases we've described already above.

EDITING A SUBMITTED PROJECT.

Login in.
Go to industry dashboard.
Choose a project and apply an editing action.
Save.

DELETING A SUBMITTED PROJECT

Login in.
Go to industry dashboard.
Choose a project and apply deleting action.
Leave a message describing reason of deleting the project as required by the system. Project will be in pending state until completely deleted by coordinators.

UPDATING ACCOUNT INFORMATION

Log in.
Go to profile page.
Link to update account info.
Change a particular information as instructed by the system.

ANSWERING QUESTIONS RAISED BY COORDINATOR ABOUT A PROJECT

Log in.
Go to industry dashboard.
Select a project and open the message log corresponding to the project.
Scroll the log to view all of the emails between coordinator and industry.
Answer the questions raised by coordinators by entering a new message.
Send message and view it on the message log.

Course Coordinator

The Course coordinator will use the system once a project has been submitted. Such projects will appear in the coordinator dashboard component of the application. At a high level the coordinator can look through the project's details and either:

Contact the industry partner that submitted the project proposal using the Messaging facility. Messages regarding clarifying details can be exchanged here in a single point of reference. All communications get emailed to the industry user notifying them of updates. Any project description changes will be reflected on the project details page.
Make a decision immediately about the viability of the project. Once a consensus has been reached, status buttons will move the project into either the 'Accepted', 'Rejected' or 'Pending' status.

VIEWING PROJECT AT DIFFERENT WITH CORRESPONDING OPTIONS TO APPLY

Login to system (back end).
View list of projects in various stages (Newly submitted, accepted,rejected,pending with Industry,archive of past years, etc,.).
Detailed view of a submitted project.
Options to make a decision (accept, suspend, reject or delete from database) or to send back to industry with more questions.

RAISING QUESTIONS ON A PARTICULAR PROJECT TO THE INDUSTRY

Login.
Go to admin dashboard.
Select a project.
Specify the subject and actual content of the questions.
Send questions to the industry via email with an message record stored in the database.

PROCESSING A PROJECT

Login.
Go to admin dashboard.
Link to accepted projects.
View and add those projects that coordinators want to process at current time to the current processing list that.
Select a project from the processing list.
Editing the description of the selected project to have more updated information from the industry.
Viewing students who have newly enrolled at current time with some basic information about them including programming skills, CS concepts or course-works completed, etc.
Assign students to the selected project.
Finally send them an email containing the link to view the project specification and details related to the project.

UPDATING ADMIN PROFILE

Log in.
Go to user profile.
Update specific user information following instructions by the system.

MANAGING USER ACCOUNTS

Login.
Go to user management link.
View, edit, destroy user accounts or create a new account (for both industry or admin account).

ACTOR: STUDENTS

View information gathered throughout the project viability process.
View contact information for the Industry Partner.

####GUI Mockups Links: The mockups for system interfaces can be viewed via the link below: https://drive.google.com/a/student.adelaide.edu.au/?tab=wo#folders/0B7_FT3mgsP8aaktBeHozN1hUT2M

####Implementation Model: The overall architecture of our application was based on Model-view-controller (MVC) pattern which was provided by Rails framework. Accordingly, our system design was considered on each aspect of this pattern.

For model, according to the use cases we got, we have to deal with three main types of data: data relating to users, data relating to the projects and data relating to the messages communicated between admin users and industry users about a specific project. Therefore we come up with the following models for managing those data:

Project: contains information about a project submitted by an industry.
Attachment: holds text-like files for each project submission.
Spec: holds an editable specification for the project. After gathering all details of projects, we can edit spec to generate a comprehensive description of the project viewable via a webpage.
User: contains personal information about the user and some information specifying the types of user - either a system administrator or an industry user.
Message: contains details of the messages that have been communicated.
Assigned student: used as means to refer to an inactive actor in the system.

In order to organise projects and its related data or models in a structured way to look up and manage we have associations established between them as follows:

Project: Has one spec, has many messages, belongs to a user and has an attachment attribute (managed by gem).
Attachment: Belongs to a project.
Spec: Belongs to a project.
User: Has many projects.
Message: Belongs to a project.
Assigned Students: Belongs to a project.

We think the way we divided data areas and associating them into these models are compact and consistent, making it easy to manage and predict for later maintenance.

For controller, this relates to more of actions so by examining the transactions and actions we have so we separate them into 4 main areas:

Controllers for security, authentication and user management:
Session controller manages sessions of users and provides authentication mechanism for all other controllers in the system, making user the system cannot access randomly out of the authorised range.
User controller manages login and registration activities including viewing, resetting or updating user information, etc.
Controllers for administrators or coordinators to carry out actions on projects submitted.
Dashboard controller gathers functionalities that administrator can use to manage the submitted projects. Admin can view/edit/updating projects based on their status and validate or make a decision on a project or view message log and send an email to industry user.
Project processing controller allows administrator to edit a specification of a project that can be viewed via a webpage and then send it to students assigned to the projects.
Project spec gens controller is used by the controller above to manage the use of gem for generating a specification for the project.
Controllers for industry users to manage their own projects:
Industry controller contains necessary functionalities for user to submit, view, edit or delete their projects. For each selected project, industry user can view message log and answer questions raised by coordinators
Mailer for mailing services within the system
User mailer: provides emailing functions for uses in other controllers which come with different templates depending on context that is used.

For view, views are developed in line with the controllers. However here we talks about the overall view of the application:

Every page of the applications will contain common sections like a banner, a link bar for navigating between pages. These are separated into a common folder for rendering in appropriate pages. The design was made so that it stays consistent with the Adelaide Uni webpage including styling and colouring stuffs.
For general users, we have links to login and signup pages allowing user to gain access to the system via an authoritative ways.

Once logged in:

If used is administrator, he will be provided with two links: one to project management and one to user management pages.
In user management, administrator can navigate through options to apply an action to the user account on the left hand side
- In project link, administrator can view project list at a specific status through left hand side. Once clicked on a project, he will be provided with a set of options to apply to the project on the right hand side.
- If user is an industry admin, he will be provided with the similar structure of view, but the options he can access are limited.

Generally we consider our view design was consistent with the natural common navigation behaviours of most users. The flowing of pages is predictable and not tricky for general use. The view does not going to deep into the tree structure rather stretching out with means of multi-options bar, which makes it easy for users to find out the needed functionalities.

#####Other design options we have considered and design changes:

Model considerations

Regarding user models, we used to consider separating them into industry user and admin user models however we realise that they share with quite a lot of common attributes and separating them does not offer much advantages. Actually with a limited types of users in this application, these two models were not a bad choice, it can gives us quick view what they are and how they are going to look like. However in contrast it made the user management implementation a bit harder and requires repeated code for referring to the common actions or for accessing the same data. By combining both into one user models, we can see a more logical view of the user system. Moreover it can adopt new types of user accounts without much troubles of changing things.

About project model, we used to discuss with the other group in our cluster about a common project model for both two group. This was not a bad idea since we will make our system as a whole more compact. For past projects, coordinator can look through the project system and pick out one, and then upload needed extra information like images or final presentation, etc., for the project to showcase. The system like that would be ideal but it is too expensive for the current development situation. We want a way to separate sections each group will develop as much as possible so that the integration phase will not cause many troubles for both groups. Working together on the same model require us to follow a strictly careful standard guides to not interfere or cause damage to the works of the other. Moreover combining so many things into one model would make it heavy each time we load data especially project model is definitely the most frequent things to be accessed by the system. By separating things into two different models solves all of those problems and still remain the logic we got – one specialised for descriptive information and one for showcasing.

Reference Number System/Registration Workflow:

Our initial implementation originally featured a reference number system to uniquely identify/reference projects for prospective industry partners. We intended to allow industry partners to update their project information and communicate with course coordinators (the basic application workflow) simply by entering the project reference number. Our initial motivation for this system was to make the process as easy as possible for prospective industry partners to submit their project proposals without slowing down the process by making them create and account and login. Seeing as ALL project ideas resulted from course coordinators proactively contacting industry, we thought this would be the most effective solution. As we iterated through design changes and eventually designed push notifications (via email) it became apparent that there would be no benefit gained from notifications if we were unable to identify the client about any changes in their project design. We also decided that if we were gathering information like name and email address to implement push notifications, we should force industry registration to maximise usability and longevity of our system. In our original design, we believed that the lower security and lack of accountability was justified to 'get our foot in the door' with prospective industry partners. Our implementation is now far more secure as it stores user authentication via SHA1 hashing encryption. This method also allows coordinators to use send follow up emails to industry partners in following years to obtain more projects by sending out a newsletter, further advertising the program and our need for projects.

Modified Layout of Dashboard:

The previous interface design was based on the GUI prototype developed from last semester which provided an overview of main functionalities we have to implement ant. Generally the design gathered all piece of information and operations into few pages. Since initially project schema contains only few simple information, the design generally does not cause any convenience. However when adding more stuff for project model, we recognize that the interfaces is un-scalable and have a bad maintainability as well as usability. The way of dashboard works was initially considered to be a bit tricky for user and needs careful instruction guides for the first time of use, though they might figure out. For example, we have to add a project to a working list before being able to process it, and this concept is hard to be learnt from the interface (though we can provide instructions using JavaScript but it was a bit awkward in our consideration) Due to these reasons, we decided to change the flow of page and redesign the dashboard so that contains a better usability and maintainability. Specifically the design now base on the natural flow of prediction of users, what they are expecting first, next and so on so forth. Based on this we come up with the current design which allows user to explore the application in no time and feel more convenient when using it.

Modified Styling:

Initially, for the main purpose of building the overall guide interface for ruby and rails coding elaboration, the colouring and styling stuff were used without considering the aspect of consistency with university webpage. Together with changes in the dashboard, we also want to have a better consistency with the layout of the unit webpage. This became reasons for restyling the appearance of our application.

Methodology

Task division

The overall task was first divided by group. We found that there was a clear distinction between displaying the Past Projects, and the system that managed new projects, and it was a logical splitting point. However as we were working on the same code base, some components were shared. Our group (Group 7) took responsibility for all of the shared components including:

Entire login system (including email password resets, user profile modifications, new user setup/admin)
All CSS styling (for main framework - some specific styling was done for individual pages by group 8)
All HTML framework (page div setup and routing)

Within our group it was obvious that there were further clear divisions of functionality and we split up the project idea management section into 3 main parts:

Login System (All account permissions/authorisation and password resets)
Admin Dashboard (Including messaging, Student-Project Assignment)
Industry Dashboard (Submission, Idea Revision, Email notifications and Messaging)

Problems

Our biggest and most crippling problem was that of cluster motivation. Ruby on Rails has a fairly high learning curve and the Rails paradigm is quite different to many other conventional languages and frameworks. Because of this, some in our group and cluster found it very difficult to get started with basic functionality and deferred setting up their environment and starting work on the project until very late in semester 2. This problem turned out to be very hard to overcome, despite setting up a Facebook message group to enforce accountability and provide encouragement.

Another technical difficulty we had was enabling email notifications due to the was in which the University servers provided to us were set up. The servers were very tightly locked down in terms of fire-walling and security rights meaning that getting access to certain ports to sending outgoing emails proved very difficult. In the end this problem could not be resolved by us as it fell outside our access permissions, however we overcame this issue by developing primarily in our own development environments, further exacerbating the above issue.

Collaboration Tracking

Our initial progress tracking and management model consisted of the current SCRUM master appending this weeks goals on the 'Goals' wiki page. The description of these goals was very high level and did not delve into any specifics. It included the group/cluster members that were assigned to the task as well as the date it was completed. Each sprint had its own section, motivated by the requirement to post task assignments to the cs forum. This design presented many problems. As it was an open free text page, anyone could change dates, goals and assignments with very little accountability. This format also didn't allow for any collaboration between group/cluster members within specific tasks.

Once development was in full swing we opted to move to GitHub's built in issue tracking system. This presented a perfect issue/enhancement tracking platform that enabled easy collaborative communication as our team was largely geographically distributed. We utilised this system for 3 specific uses:

Sprint Tasks/Goals

At the start of each sprint, each task was created as an 'issue' with the 'Enhancement' tag. It would be assigned to the team member responsible and attached to that sprints milestone. i.e 'Week 10 Meeting' The description field was then far more detailed allowing other team members to more accurately understand the impacts of the feature. GitHub also allows comments to be added by anyone, enabling much discussion and feedback, leading to further understanding by the whole team. This also meant that there was no overlap on task domain which was a problem we initially faced. This system also allowed us to track progress against our next milestone deadline as GitHub provided a graphical representation of the current sprint progress. It also meant that when appropriate we were able to reassign a task to a different member whilst retaining all previous information and previous assignee as needed.

Bug Tracking

We also used the issue system to track bugs. Whenever any team member noticed a bug in a fully implemented feature, and issue was raised with the tag 'bug'. This allowed features to be more thoroughly tested as a wider range of users (multiple platforms etc.) provided feedback. The issue would then be assigned to the team member that originally implemented the feature who would receive a push notification and be aware of the bug immediately. Once the bug had been rectified and committed to a branch, the branch name was commented and the bug was closed off.

Adapting to Design Changes

Occasionally a few aspects of our design did not meet the system requirements once development had begun. As per the agile software engineering framework, we updated/modified our design. The issues section presented a perfect opportunity to discuss these design changes for everyone to see, and more importantly receive push notifications about.

Codebase Collaboration

At the heart of GitHub's very design is the branch->merge workflow design. We, of course, utilised this process throughout the course of development. As heavy development cycles began to occur we opted to perform a Map-Reduce style of branch merging. Before the next milestone, we would first commit our branch. That branch would then be merged into a group branch one at a time until the branch contained the entire groups work. Then at the cluster meeting, we would merge the two group branches into the master. This was done to maximise our in-person collaboration time whilst still being able work through and understand the other clusters design/code.

Testing

#####User Interface Style Testing In terms of user interface testing, it is unlikely that there is way to write a testing suite to test if the interface looks “nice” to user. So, hand testing will be involve to interface testing. These represents as do valid or invalid actions to see how the user interface will response to those actions.

There is another aim for doing user interface testing by using hand testing: there are multiple groups inside one cluster. It is important to show whether the product works or how the product works to other groups or customer. Although that other groups can take a detail investigate through testing scripts for those functionality testing, customers are only concerns about the whether the user interface is feasible to them.

Automatic Testing Script

Writing testing in Rspec test suite is the main test method for the automatic test system in the project which provide high portability and compatibility with the Ruby on Rails. One of the reasons of choosing Rspec testing tool to do Ruby code testing is because this tool was born under the banner of Behaviour-Driven Development and it is designed to make Test-Driven Development a productive and enjoyable experience with different features. For compatibility, this testing tool is a professional testing tool based on Ruby language which provides rich command line program, textual descriptions of examples and groups and flexible and customisable reporting. For portability, Rspec testing tool provide embed testing script that wherever developer checkout the code, all embedded testing suite written within the project directory will be checkout at the same time. Therefore developer is able to do testing in any devices that they used to developing this Ruby project.

Rspec testing suite provide a good structure which developers can describe the test case and prompt out the test cases description when the test failed. Each test cases will be surround by a description that developers can understand what a specific test cases is testing on at a glance. There are model testing, feature testing which model testing is to test if the database schema meet the requirement and the feature testing is actually testing the functionalities and user interface together. Due to the case the interface layout has been carefully tested by hand which has mentions before, there is no requirement for a test script to validate and layout for webpages. Therefore cases for user interface is manly iterator through different views, simulate human’s valid and invalid input and check for result behaviour but not checking any “beauty” style.

As the consequence of doing this kind of testing, more specific bugs can be easily find out to fix on with. And it is very easy to retest everything by just few commands on terminal when some new abilities added to the product.

Group Work

 Describe the division of work. This need not be a long story - just a brief statement of who did what. You may mention who has done what as you describe each section of the implementation (in section 3), however it is always a good idea to have a section summarising the division of work.

*Sam - Login System, Profile, Industry Dashboard Design changes *Khanh - Admin Dashboard, html, Index *Linsheng – html, test

Group work is basically separating a big project into small pieces therefore every person inside the group can take individually implement one pieces every time. This is a very important process especially using an Agile processing model because Agile model includes frequent meetings to keep the progress in right track.

There are three people assign to Group 7 and this consequently make the division much easier than more people inside a group. This is because larger the group is, harder the communication is and it has a higher possibility that unbalance work amount been allocated so that the one who got larger amount of works will not be able to finish on time.

The webpage development part has been divide into three main section: user login and profile system, admin dashboard system and industry dashboard system. Therefore Samuel Reid took the user login and profile system, Bui Khanh took the admin dashboard system and Linsheng Wu took the industry dashboard system.

There is no logs of works for weeks before week 6 due to a reason: not yet been working on the GitHub system. That was because the decision the cluster made was to complete the requirements, design and documents on Google Drive and Google Document that each member can easily access any pictures. Also Git accounts was not well reorganised and coding session has not been start during those weeks. A benefit for working things on Google Document is that Google Document provide extremely powerful document edit abilities which is very suitable for edition and synchronisation on requirements, design and documentation. As the result shows, there were some good documentations been produces for the project on Google Document.

About week 6, work assign to each member every week was started to be record on wiki at Git hub. To make the detail clear in this report, jobs done each week and summarise for those job will be represent below:

On week 6, work space for the project was moved from Google Drive to Git Hub. Therefore after the design section for overview, Bui Khanh and Linsheng Wu started to build some basic html webpage up for project. Bui Khanh also uploaded some prototype to Git Hub and tried to start some Ruby work on index page while Linsheng still building the html page for admin dashboard. Samuel was busy on doing some work outside of school. However, he joined some discussion for group agreements.

Outcomes for week 6 is quite useful for project because most of Ruby webpages setup are based on those html webpages later. The purpose to make those html files first was that html webpage are easy to test by simply parsing them into any web browser. Those webpage are built as similar as possible to meet the layout requirements within the prototype design and some specific functionalities were added such as the “JQuery date filter for dashboard” and so on. The Git Hub account was not well reorganized until the end of that week. Because of that, work done from Linsheng cannot be commit to Git Hub and Bui helped for this problem by created another permitted branch for Linsheng.

For week 7, Samuel Reid started to build the login, profile and register system. Bui Khanh finished the index and admin dashboard setting up and continued to add some functionalities into admin dashboard. Due to a terrible illness, Linsheng Wu was just be able to do some small tests on html pages and ruby pages.

The login, profile and register system is actually authorisation system. Dividing this system out from the webpage part because it was discussed that this could be a separate part from the webpage. Without a complete authorisation system working, a fake or temporary account can be used to analyse if other part of the project is working. Some databases schema also been discuss within the group discussion and been set up for using. These databases are very important for creating any further working information storing based system such as saving projects, saving students and so on. To make sure the confidence with database usage within the cluster. Group 8‘s members were acknowledged with the databases schemas created. Tests are small which includes normal testing and error testing directly on the Ruby webpages since those webpages were just built up and issues or bugs were notified through the email system initially.

In Week 8, Samuel Reid finished the login, profile handle system but still working with the register system and fixing some bugs for permission part. He also merge up the login system, index and admin dashboard to make sure the master branch in working repository is up-to-date for every member within the group and he tried to start to fill up and create some templates for some sections in final report. Bui Khanh tried to start a hard part which is auto mailing system and he finished other functionalities for admin dashboard and database setup for that week. There was a problem that the design for industry dashboard is not specifically enough so that Linsheng Wu was tried to restructure out the Industry dashboard and start to build it up in that week.

Merging branch on that week was successful. Bui’s index part was updated that banner and navigation at the top can be separate out and easily added to other webpage by just using one line or two lines of code. Due to completion of database and models. More tests were added to test the functionalities and some test suits were built up for those models to test validation abilities.

In week 9, Samuel Reid was trying to create more functionalities for authorisation system as create user profile edit system, create password reset system and user permission group. Bui Khanh has finished the auto mailing system which works properly and start to modify dashboard layout because a discussion concluded that a project must have more variables to contain some key dependencies which are outstanding from project description. These variable need to be place in an extra field on dashboard so that they can attract attention from user such as “how long will the project takes”, “how many students will be involve with the project” and so on. He also merged works during cluster meeting session. Linsheng Wu has finished the basic setup for dashboard and start to add a new feature called delete pending into industry dashboard. This is because a discussion on cluster meeting also decided a delete pending ability need to be add to industry dashboard so that industry’s project will not be pending to delete and notify administrator instead remove immediately.

Merging was successful and the webpage part was much closer to finish at that week. However, change structure in project introduce to changing database. Database need to be update before adding any webpage views that it would be clear how many extra fields needed to add. Due to this reason, view changes were delayed until completion on restructuring on database.

Week 10 is a week which contains an important interface design change for project viewing style on both Industry dashboard and Admin dashboard due to the finished changing on database which was planned to do on week 9. The group discussion also decided that the style for the webpage should be more similar to Adelaide University’s school website. For project list viewing page in Industry dashboard, the original small list layout design has been changed to a big box layout design which each big box just contains single project to make Industry user easier to click on. For Admin dashboard, the project list viewing page changed from a small list layout to a big list layout to make Admin user to have a better concentration on project management. Specification area should be remove from project list that users can click on a project to go into another view to see description and extra fields. Therefore Sam took the interface changing part for project list viewing, Bui took the style changing part And Linsheng Wu was planned to add more Rspec test cases that week that group 7 was able to have a complete feature showing and tests showing for presentation on week 11.

At week 11, the project implementation for group 7 was finished, every one inside group 7 was tried very hard to do preparation for the project presentation on Friday. There was a big merging and functionality testing on cluster meeting that week to make sure everything works correctly on the presentation not only for group 7 but also for whole cluster 3.

As a result shows that week, merging was successful and group 7 has produce a working product and test cases function normally as well. Those functionalities has been fully presented on the presentation. However, the time for presentation was not well organised that Linsheng Wu has not got enough time to introduce many non-functionality features including the testing features.

Week 12 is the week which right after presentation. Everyone getting so busy on assignment and group 7 is going to keep on with the testing phase for project. So Linsheng Wu was planned to add more and more test cases that Samuel and Bui can fix anything expected failure on the project.

Final Product

 Description of the final product you have produced, i.e. your overall achievement. What have you implemented? What have you not managed to implement? What were the difficulties: which did you manage to overcome, and how? Any novel results (this would apply more to investigative projects than to implementation projects)?

For the final product which produced by group 7, a basic product type definition will be a web server based engagement application which wrote in Ruby on Rails. The aim for this web server application product is to improve the efficiency for Industry people from whatever companies who is going to provide some projects to Adelaide University can submit their projects easily via the web server application and for the course coordinator who is teaching Software Engineering Group Project (SEGP) be able to manage all of projects which submitted by those Industry people.

There are major three aspects of implementations for the final product:

The first aspect is the authentication implementation for the engagement system. Without this implementation, no user can start using the engagement system since no admin or industry people can be define. This authentication system has been implemented as that users can login, logout, register, reset password and so on. These actions lead user to use different dashboard sections after they login decide by different account types.

The second aspect of implementation is for industry user which is the industry dashboard. This dashboard has been implemented to allow industry users to change their profile, submit new projects, edit or remove projects, view project, contact admin user and so on.

The third aspect of implementation is for admin user which is the admin dashboard. This dashboard has been implemented to allow admin users to view submitted project from industry people, manage project by using different states, contact industry people and so on. They are also be able to manage user accounts.

There was a difficulty when implementing those dashboards. There was no actual requirement that it is very hard to decide the final layout for those dashboards. This consequently produces some design changes when doing implementation or even after the implementation finished.

In overall, the most difficult aspect for implementation is to use a language which is unfamiliar with to implement something. This costs a lot of time on language study and causes a lot of problems when doing error check or even doing communication between different developer groups.

However, the final product has been fully implemented to achieve the initial goal and it has been merged with the product which produced by the other group within this cluster.

Evaluation

In this case project 'success' is very hard to define. A typical measure of success would involve a comparison of the final product against the client's need. However, our project cannot be measured in this way for a number of reasons. Firstly, the client-derived specification given to us consisted of a single word 'Engagement'. We were asked to come up with a design for some kind of system which helped the course coordinator (Kevin Maciunas) run the fourth year Software Engineering Group Project (SEGP) course which would help engagement. Whilst we asked for a more specific specification or, at the very least, an idea or starting point, we were told to come up with something ourselves. In the end we came up with the above specification. As it was completely designed by the project team building the application, it is impossible to compare it to the 'client' specification as it was built exactly how we chose to build it. Another reason why it is difficult to judge its success is we had very little outside validation throughout the development process. In our system, there are two groups of typical users; Course Coordinators and Prospective Industry Partners. After the design stage was completed our one and only coordinator client, Kevin, was no longer present. This meant that for the entirety of the development period, including all coding sprints, we had no one to validate the work we had done during the sprint other than ourselves. This made it extremely difficult to judge usability of the system, especially as no University of Adelaide students would be using the system at all.

Luckily, one group member (Sam) is currently employed as a Technical Specialist at Westpac's IT Service Desk, which has provided projects for fourth year students for the last few years. This provided some access to validation from a industry user perspective. A prototype was demonstrated to a member of the service desk on three occasions. The feedback received was always generally positive, with a few constructive comments in regard to our design.

At the first demonstration after sprint 3 (Semester 2 Week 5), they advised that the setup and usability was quite good from an industry standpoint. However they were concerned that allowing external users (anyone on the internet) to access projects via a reference number was not secure enough to be used in a banking environment. Taking this feedback on board we opted to remove this feature (see Design Changes above).

At the second demonstration after sprint 6 (Semester 2 Week 8), they advised that the industry dashboard lost usability once we added a few more features. When the user had multiple projects, the project would have to be selected again every time in order to make changes. Based on this feedback, we redesigned the admin dashboard to include a project selection page ahead of any modifications, making the flow more clear.

At the third demonstration after sprint 8 (Semester 2 Week 10), they advised that the look and feel of the system didn't seem to match the other University of Adelaide services they had used in their past dealings with the university. We agreed and during our final few days of development made large changes to the entire styling and look of all the pages. Another demonstration was not able to be made in time to validate these unfinished styling changes, however they are much more in line with current university branding.

From the relatively small amount of feedback we have received from the industry partner we happened to have a pre existing contact with, we feel that the project meets its requirements from an industry perspective. As we did not have a university course coordinator contact for feedback, the success of the coordinator component can only be compared against our original design. Our final product matches our design quite closely, except for the design changes proposed by the industry partner, which we entirely agree with once presented with an alternative.

Our product has a fairly low workload in terms of computational processing, however load times were tested and after quite fast. One notable exception is when the application emails industry users (password resets, coordinator messages etc.) it does take around 2-3 seconds to send due to google's authentication delay. If we had further time, we intended to implement asynchronous processing for these function types.

Reflection

What worked well and what did not?

In the beginning of the semester, the meeting was mainly about system configuration and installation and the resolving rails and ruby version inconsistencies in the provided server. Moreover everyone had very little knowledge of the ruby and rails. However, team has managed to aware of the important thing was to keep the work in progress rather than waiting for difficulties to be solved or knowledge to be filled up. Therefore we have started with building the html interfaces for the application based on the GUI prototype, which was important for team to elaborate on later with actual rail code and ruby embedded and save everyone some time for learning more about ruby on rails.

After starting to use GitHub for developing and managing project work, our communication and collaboration has been done well within group as well as across cluster. We realise that to make more interactive communication about minor issues or updating progresses or asking for helps from other. We have established a Facebook chat log for whole cluster which proved to be quite helpful for updating status of every people in frequent basis. We considered this as a good way for our cluster to compensate a daily stand-up meeting (which was hard to accommodate due to time scheduling difficulties within cluster and group).

Plans and work division has been done well in the weekly meeting with detailed goals and plan for the sprint and tasks assigned to team member were clearly specified. Generally the tasks were well done before the next sprint except for hard difficulties which was added to next sprint task.

During the semester, we have experienced many great difficulties in following agile methods within our team as well as in our cluster. Our project plan was based on agile model which considered standard agile methods like daily stand-up meeting, different roles in the sprint, and specific agile activities within a scrum meeting, etc. These aspects were not done well due to lacking of knowledge of rails and scheduling time of each team member. Moreover the process did not follow TDD in strict ways, for example writing tests before writing code principle was violated. Many aspects of agile were not being able to be done as expected. The most important aspect of agile is about working closely with client. However our main client Kevin was on leave, and therefore we did not do well in gathering more requirements or much validations from the client.

At the beginning of the semester before using GitHub, the communication between team members has not been done well due to lacking of effective means of communication and other subjective reasons.

About development part, the initial design of the application interfaces contains many inconsistencies which caused difficulties while elaborating on and therefore led to some significant changes later, which put heavy pressures on developer sides.

Suggested improvements to the process

Since applying the exact standard development model to a team context does always guarantee a successful outcome (Reasons for the existence of various process models) we suggested following activities for improvements in building up a reasonable process for a team context:

Figuring out the potential difficulties that team member are going to have in both short and long terms.
Listing out what features of the given base process model the team member cannot accommodate during the course, and design an equivalent feature that the team member can accommodate. Making sure that the team guarantee that the new compensated solution will be not among his future problem.
Listing out aspects of the process that are considered to be heavy for capacities of team member and simplify them in a reasonable way.
Preparing the convenient and appropriate facilities for team collaboration and communication. This should be put on the highest priorities.
These things must be done early and firmly in the early stage of the process and should be reviewed regularly to validate its effectiveness.
Filling skill gaps should be put on high demand in the process as well since we cannot develop the system without knowing how to use the tool to build it. Consistency between learning progress and project progress must be important point for consideration.

Experience of using GitHub within the cluster and team structures:

Through experience of using GitHub within the cluster and team structures we must admit that GitHub's a great tool for project management and team collaboration. At the first time around, it was a little confusing to every one of us about how it works and how to use it for managing our project. Because GitHub were developed based on the way the version control application Git works, it took us some efforts to learn how to use Git command line and similarly how to use GitHub then. After getting familiar with features of Git, GitHub becomes tremendously useful and convenient for us in organising and developing our work in team and cluster collaboration. The web-based graphical interface of GitHub makes functionalities of Git becomes much more convenient. It provides us various ways of managing and reviewing the code development in line by line in terms of line addition as well line deletion or means of comparing different work versions through great ways of GUI, or creating branches or merging things automatically. Though most of our coding work was managed through command line with Git, functionalities offered by GitHub have contributed a huge inseparable part of the whole course of project development.

Not only being great interfaces for distributed revision control and source code management, GitHub changed the way we communicated and we benefited significantly from those collaboration features cooperated in GitHub. We used to collaborate and update work progress through google doc drive and emails before the arrival of the offering of GitHub from coordinator. Compared to the old way of collaboration GitHub is just awesome. GitHub provided us with various active channels for communicating and reporting current issues. We can create separating topics for discussion in an organised way and be able to subscribe for updating the latest news from the development process. All of these are gathered in one place but in an ordered and logic way, which helped us a lot in contact with other people progress and status. Especially GitHub have some means of generating statistics relating to project progress and individual contribution which encouraged us a lot in participating more actively to the team work and more aware of the responsibility of each person towards team and cluster.

Generally, while frequent meeting in person are of great challenge in our team condition, GitHub has proven to be effective in resolving much of this problem by allowing the communication and collaboration in an effective and convenient way to each person.

While the great influence of GitHub on our team cluster performance is undoubted, we’ve also sometimes got some difficulties during the semester when using GitHub. Some people cannot get updated on their contributions or got confused on how GitHub and Git work. We know those difficulties were mainly due to lack of precise knowledge or missing some important configuration for an accurate use of Git and GitHub, rather than from the application side. We know the complication of how to use an application is usually clearly unavoidable and we hope we will have deeper understanding of GitHub in the future for gaining the full benefits offered by GitHub.

Experience of the first semester “flipped classroom” and the edX SPOC (Small Private Online Course).

During the first semester, we have a chance to participate in new kind of classroom – flipped classroom in combination with materials provided in edX SPOC. We considered edX SPOC gave us a convenient way of learning with offering various external learning sources apart from those that were of core content of the online course. The materials were broken down into a number of short clips of videos making it easier for us to digest, rather than overwhelming like in a traditional lecture of full 1 or 2 hours. The materials were good both in contents and the way lecturer conveyed the learning materials. All learning things was online with supported by great web tools, we could watch them everywhere in a convenient way. These materials then become the topics of almost every actual class in SEGP1/A. Since we watched them before coming to the class as told by the lecturer, we felt like we gained more of the topics from the discussion in the class. The instructions and emphasis on important points from the lecture helped us to figure out vague points we got when watching the video by ourselves, remember things better. Since the edX course material that was given to us in the semester 1 was inactive mode, we could not participate in programming assignments or practical exercises offered by this online course as we experienced before in some MOOC courses. Therefore experiences about edX SPOC was not quite complete, mainly limited to the video and learning resource mentioned. The flipped classroom were great in the way helps us to engage more in the class activities with discussion during the time and by that understand more about the material. However class lacked of providing students with some small programming assignments to help us become familiar with the new languages and framework. We believed the flipped class using material of edX SPOC has been more effective if it helped us build small steps to get along with the project with simple or small assignments in a regular basis. All of people in our group and cluster were totally newbie to ruby and rails at the time, therefore due to lacking of relevant exercises, people seems to learn in their random ways which was proven to be not quite helpful. The edX SPOC and flipped classroom if designed more comprehensively and more structured then we think it will give us much more assistance in our learning process.

Appendix 

The appendix should contain your logbook, with records of group meetings, who did what, and, if possible, amount of time spent by various group members on their contributions