case study web-based IMS and CMS for managing an online estate agency As a freelance developer, you’ve been commissioned to undertake the following development project.

INSTRUCTIONS TO CANDIDATES

ANSWER ALL QUESTIONS

CASE STUDY: Web-based IMS and CMS for managing an online estate agency

As a freelance developer, you’ve been commissioned to undertake the following development project, made up of three main modules: a “Web Portal”, an “IMS” and a “CMS”. More in detail:

1. The Web Portal is the official website of a family-run online estate agency, and should be designed as a main framework from within which it would be possible to run their business and market their products and services. This would allow:

   1. the public to access an online show-room and look for available properties for sale, gather information for each property and contact the sales team for arranging an appointment; more advanced functionalities and facilities available to the public (for example, the possibility for customers to register their details and interest with the estate agency, to save searches on specific categories of properties or within certain locations, to chat with a salesperson, etc.) would be considered as an extra value added to the system and would be therefore suitably considered;

   2. staff of the estate agency to access (by using some secure login facilities) and run the following:

2. A database-driven web-based application to manage relevant details of the business, such as the properties for sales (including their purchases and sales), customers (both sellers and buyers), staff, events, services offered (e.g., property evaluation, independent mortgage brokerage, removals) etc. This application is the Information Management System (or IMS) and should be accessible and usable only by members of

3. A Content Management System (or CMS), which, like the above IMS, should be manageable only by members of staff in order to populate and control what is published on the above-mentioned Web Portal. The CMS should support the easy management of the back-end of the online show- room, to include not only all needed details (e.g., photos, location, typology, price, etc.) of any property for sale, but also the possibility for staff to publish and advertise on the pages of the online show-room any relevant news for customers, like latest entries, special offers,

The system overall could and should support several other functions (e.g. from administrators’ login to the possibility, for staff or customers, to choose from different graphic layouts of the showroom), which you, as an expert, have been required to identify and/or suggest.

The software development part of the project is to be performed on any development environment and technology of your choice, as far as the final developed product (i.e., the system overall, made up of the above three modules) can be run from/on a (set of) server(s) you can control (likely, but not necessarily, on your own machine: for example, a local instance of Apache web server, MySQL database server, etc.), and can be used and tested via Mozilla Firefox, or any other browser which adheres to the same W3C standards Mozilla Firefox adheres to. If you are unsure about which

development technologies to use, we would recommend a simple “development platform” based on PHP and MySQL, ideally enhanced by a PHP development framework of your choice, and by any relevant client-side technology (HTML, CSS, JAVASCRIPT, etc.), again ideally enhanced by some available front-end facilities such as jQuery, Bootstrap, etc.: the easier way to start setting up your development environment is to adopt (and “adapt”) a WAMP stack, if you are working under MS Windows, a LAMP stack if you are working under Linux or a MAMP stack if you are working under Mac. The development environment and the engineering process(es), which you are expected to set up, get familiar with and rely on, should include facilities such as a version control system (e.g., Git),

 

unit testing (e.g., PHPUnit), web testing (e.g., Selenium) and bug tracking (e.g., Bugzilla). More details are discussed in the following sections of this document.

 

 

SUBMISSIONS

The project described and expected by the case study is to be delivered in two stages [which map to the two coursework assignments!].

The format for each assignment and further submission instructions have been specified within the respective Assignment Briefing Sheets.

Specifically:

The first delivery [CW1] is worthy 40% of the whole assessment for this MSc module and would consist of a report of about 4,500 words (excluding references, image captions and bibliography), to be submitted in both .pdf and .doc (or .docx) format.

The report should be professionally formatted and should include a title page, contents page, executive summary, page numbers, appropriate headers that have your full name and university e- mail address, references, bibliography and any appendices if needed. Overall, it should appear as once cohesive document. The main body of the report should be organised in three sections, including respectively:

1. A system specification relating to the case study. Not only will the report be expected to detail functionality, but it will also be expected to detail development schedule: as the project must be tested and completed by the submission deadline stated for CW2, in CW1 you should therefore consider also what is expected for the subsequent deliverables (see point c below and CW2). [10%]

2. The process model you have chosen for development, which you should specify and fully justify with a detailed (and comparative) description of the chosen model and an explanation of how the chosen model will affect the development. You should also review available and relevant literature in search of justification criteria of the process model to be specifically applied to your design and development decisions. This specification is also part of the 4,500 words report. [10%]. c. A description of the first release of the system being implemented (all three modules should be considered: and each of them should display some working functionalities already, although emphasis should be placed on the official web-site) and its

‘look and feel’, to be consistently adopted over all modules of the system (e.g. the same .css file or files should be used for all three modules). In this section a number of screenshots taken from all three modules (overall, up to 35) should be included, together with a short description/explanation of what captured GUIs are about, how the user is going to interact with them, and how these have evolved alongside the development process model, as chosen and described in the previous section b. At this stage, the student is expected to perform a thorough evaluation of the system developed so far, and plan for any improvement s/he is expecting to pursue in the final release of the system. Navigability, accessibility, rationale and overall feel and look will be the main assessing criteria for this section. Also, quality of description and evaluation (together with an improvement plan) as well as quality pictures, in terms of both readability and relevance, will be considered for assessment [20%].

 

• The second (and final) delivery [CW2] is worthy 60% of the assessment for this MSc module and should relate to the final release of the implemented system (all three modules should be included and fully working): it would consist of a second report and of a demonstration video in .avi format (possibly built with Camstudio).

This report, expected to be of about 5,500 words, should be submitted in both .doc and .pdf format. As for the one produced for CW1, the report should be professionally formatted and should include a title page, contents page, executive summary, page numbers, appropriate headers that have your full name and university e-mail address, references, bibliography and any appendices if needed. Overall, it should appear as once cohesive document. The main body of the report should be organised in five sections, as follows:

1. A first section, regarding testing of both the IMS and the CMS modules. As these two modules should work against a suitable number (between 20 and 30) of relevant functional requirements, for each requirement you should be able to identify at least one reasonably challenging test (e.g., how the system would handle an attempted division by zero). All these tests should be provided into a list first and then individually described. For each test, one or two representative screenshots of the system should be provided for clarification purposes. It is the appropriateness and completeness of the testing exercise, as well as the successfulness of its implementation, that will be assessed [10%]

2. In the second section, one module only of the system (chosen by you) has to be thoroughly tested by using Bugzilla or a similar bug tracking system: relevant reports and a number of screenshots (between 10 and 15) should be included. By means of this section, you should provide evidence of how confident you are in using your bug tracking tool, and quality and relevance of that evidence is what you will be assessed against [10%]

3. All modules should be developed using an appropriate application of the ModelView- Controller (MVC) architectural pattern, or of any similar variation of this pattern (e.g. MVP,

MVVM). Evidence of the application of the pattern should be given in a third section, in

which you should explain how you (and/or the technology you’ve adopted for this project development) have pursued the MVC (or similar) pattern, also by referring to some shorts (possibly commented) pieces of code and to the system architecture as a whole, i.e. the way in which the files “making up the program” have been structurally organised. Larger chunks of code should be put into an appendix of the CW2 report and will not be considered within the 5,500 words limit. Assessment criteria would include quality and quantity of evidence provided, their relevance and how confidently the student has managed to master the MVC pattern (or one of its variations). [10%]

1. Software for this second and final delivery should be developed by relying on a version control system (VCS) of your choice. Evidence of this should be given by producing a fourth section of the document, in which the diverse versions of one file only (of students’ choice) have been retrieved from a VCS repository, with some accompanying screenshots of the VCS system related to the retrieving process. Again, quality and quantity of evidence, together with how the student has be able to demonstrate an achieved confidence with the technology and the approach, will be considered [10%]

2. A Post-mortem analysis and reflection of the overall development process, including what you have learnt, what you think you have done well, what you might have done better, and a plan of how you would implement further improvements, should be included in the fifth and last section of this report. Your post-mortem will be assessed against criteria such as depth of analysis, extent, an ability to self-reflect and critically assess your own learning achievements,

 

and the quality by means of which you’ve developed this last portion of the CW2 submission

[10%]

The video (to be named CW2.avi), no longer than ten/fifteen minutes, should provide evidence of how usable and rich in terms of functionalities and features is the system across its three modules. This part of CW2 will be assessed against the quality of video in itself but also and above all against the actual features, the usability and the overall feel & look of the system [10%]. If the video is not commented live by you, it should at least include some subtitles and/or captions supporting its comprehensibility.

Attachments:

Expert's Answer

660 Times Downloaded

Related Questions

. Introgramming & Unix Fall 2018, CRN 44882, Oakland University Homework Assignment 6 - Using Arrays and Functions in C

DescriptionIn this final assignment, the students will demonstrate their ability to apply two ma

. The standard path finding involves finding the (shortest) path from an origin to a destination, typically on a map. This is an

Path finding involves finding a path from A to B. Typically we want the path to have certain properties,such as being the shortest or to avoid going t

. Develop a program to emulate a purchase transaction at a retail store. This program will have two classes, a LineItem class and a Transaction class. The LineItem class will represent an individual

Develop a program to emulate a purchase transaction at a retail store. Thisprogram will have two classes, a LineItem class and a Transaction class. Th

. SeaPort Project series For this set of projects for the course, we wish to simulate some of the aspects of a number of Sea Ports. Here are the classes and their instance variables we wish to define:

1 Project 1 Introduction - the SeaPort Project series For this set of projects for the course, we wish to simulate some of the aspects of a number of

. Project 2 Introduction - the SeaPort Project series For this set of projects for the course, we wish to simulate some of the aspects of a number of Sea Ports. Here are the classes and their instance variables we wish to define:

1 Project 2 Introduction - the SeaPort Project series For this set of projects for the course, we wish to simulate some of the aspects of a number of