[Project] innovating digital systems/services

##Introduction

You have to complete a project as part of this course, this chapter provides information about and instructions for the project.

##Essential reading

Pressman and Maxim Chapters 2 and 3 (again)

##Further reading

Dawson, C. W. Projects in computing and information systems: A student’s guide. (Harlow: Pearson, 2015) 3rd edition [ISBN 9781292073460].

##Overview

For this course you are expected to undertake an individual innovation project and to submit a project report to London. You should take some care in selecting a project topic and preparing for this substantial task. To achieve good results in this course you will need to devote substantial time to this project and ensure that you work on your project consistently over the year. There is no way that you can rush the project at the last moment.

The idea of the project is to demonstrate an understanding of the software development and innovation process and of professional practices. It is not intended to be about producing a computer program, and you are not required to deliver a computer program with your project.

The crucial part of your project is the description of the development process, which is a model-based task. It is your job to create documentation that can support a programmer in his tasks of implementing your models and ideas in form of programming code and of testing the resulting system once it is operational.

The time you devote to your project will also be of benefit to you when it comes to sitting the examination. The experience of developing your own project will show through in the examination. It will provide you with important examples of how systems development works in practice. You will know what you are talking about. Indeed the problems, frustrations, moments of breakthrough, difficulties and joy you will feel undertaking this work are the same as those experienced by system developers in their daily work.

In a section below, I recall the project ideas (first listed in chapter 1) of possible projects that you might like to consider. You are, however, encouraged to develop your own project idea for a small or medium scale software system. In general, you should understand that we are looking for a system that allows you to carry out a development process that leads to a set of models for a complete system. At the end of the project these models should be capable of being easily developed as software code by a programmer.

##The project is intended to:

-take you through the process of identifying and developing a digital system, tackling a realistic problem

-provide practical demonstrations of the key issues discussed in the subject guide. It is when doing the project that you will come to realise the importance of good requirements analysis and design, the benefits of setting up a proper testing process, the problems of keeping to deadlines and managing projects, etc.

-be an enjoyable experience where you can make the mistakes that you will learn from.

In order to complete the project you are required to produce a number of documents. It is very important that you maintain coherence between the documents you create.

In addition to these documents, you are expected to write a final project report. The main section of the final project report provides a summary of the lessons you learned, what went well and what you would do differently next time.

You should note that the focus of the project is not on the system produced, but on the quality of the process undertaken and the coherence of the documents presented.

One way to think of the project is as an attempt to produce a set of documents which could be sent to an outsourcing company to ask them to produce a system for you. Your aim is to produce a set of documents which would enable the outsourcer to understand what was needed, and go ahead and produce the complete software system.

##Submission

Details on how to submit the project and the date by which the entire project must be in London are given in the booklet Completing and submitting coursework and projects, which all students taking this course should receive. This booklet is revised each year, and you should make sure that you have the most recent edition. The booklet contains the exact deadlines for each year, the forms required to accompany your project and details of how to submit the project.

##The project as a development process

The aim of the project is to give you the experience of the processes and practices of system development. As such, we intend you to undertake the process of analysing and designing a software product and submit to us the documents you used in this process.

This means that the documents should be the practical documents you would use to develop the system. Before you hand your project in you could of course go back over your individual documents again and edit them. However, the examiners want to see a development process complete with revisions that are typical for iterative or agile development. For example, examiners would be happy to see a page in the later stages of design which said something like The initial user requirement for XYZ was unachievable as it conflicted with the other requirement for ABC. It is therefore decided to drop XYZ from the design. What is important is that the project documents demonstrate how problems faced were addressed. Examiners want to see a genuine learning effort that uses the methods and techniques introduced in this subject guide.

Finally, it is essential that your documents form a coherent project in which the examiners can see how the individual development stages have been carried out and how they relate to the previous and the following stages. We are much more interested in how you progressed through the various stages of your project than in the final result.

##Use of diagramming editors and tools

You are encouraged to make use of diagramming editors and tools in your project. There is a wide range available, for example StarUML and draw.io, but you can choose the editor/tool that suits you best. However, this is not a formal requirement so do not feel you have to.

##The project proposal inception and planning

Your project proposal should include

-an overview of the system (project inception)

-the choice and justification of the development process model you will be using

-provide a clear timetable of how you are going to complete your project.

##Project Inception: project overview (2-3 pages)

Present an overview of your project idea:

Give your system a name.

Provide a statement of need and feasibility: Explain why the system is needed. Describe what the system will do and who its users will be. How will it help the users? Discuss any issues of feasibility.

Provide a statement of system scope: Outline the most important features of your system.

Provide a list of all relevant stakeholders

A description of the system’s technical and physical environment: Where will your system be used? Are there any other systems with which the new system will interface.

Are there any important performance goals for your system: time or space efficiency, security or reliability?

##The development process: choice and justification (1-2 pages)

Chapter 3 of this subject guide introduced a number of different system development process models. In this section you should describe the development process you intend to employ, and how this is relevant to the system you describe:

Outline the basic principle of the chosen process (including references to relevant literature).

Discuss why this process is suited to the problem, which you previously described.

##The development process: planning (1-2 pages)

It is your job to decide on how you are going to execute the various activities that are required by your chosen process. You should now:

Provide a very detailed timetable for the activity you are going to undertake and a detailed plan of the documents you will be providing. Your chosen development process should help you to establish a structure that addresses the need for requirements elicitation and analysis, design and elaboration (including UX design), testing and aspects of deployment. Your decisions may depend on a number of factors including the development process you have chosen, the stakeholders involved, the nature of the problem you are trying to solve.

Planning is an important task, as you need to ensure that you can complete all the necessary documents on time. You should not take it lightly, and should use project management techniques to help you plan. You should ensure that you produce a timetable (possibly a Gantt chart) for undertaking the project, including plenty of contingency time should things go wrong and including time off, holidays etc. It is important that you balance the demands of this project with the need to study the subject and relax. Remember that the project accounts for 40 per cent of your mark, and should therefore constitute no more than 40 per cent of the time you spend to study this course.

It is essential that you stick to your timetable in order to avoid severe time pressure towards the end of the project and to get maximum benefit from the project. If you start your project too late you will not have enough time to carry out all the stages that are part of the development process.

Consider any problems you might envisage encountering and how you intend to manage such risks.

##Documentation of the development process

Section 2 of your project will form the main body of your coursework document. Part 2 of this subject guide introduced you to the practices or modelling techniques that are used to support the various tasks of numerous process models. You are expected to use these techniques within your project.

The exact format for this section depends on the development process you have decided to follow (as detailed in section 1). For example, within a more agile iterative development, communication and planning may be repeated in a loop several times, before modelling is carried out repetitively. It is left to you to find the best structure for your deliverables section 2.

##Examples of the documents you might produce for different processes

It is your job to find the structure that suits your development process best. However, here are a couple of examples to give you an idea for a possible structure.

Most of you will probably choose some form of an agile development process. As you are not expected to do any programming, it is important that you stress agility in the activities such as requirements elicitation and design.

##You might have a document of this form (or similar):

-Development Cycle 1

(a) Requirements elicitation.

(b) Establishment of non-functional requirements

(c) Scenario-based system modelling

(d) Testing

-Cycle 2

(a) Further requirements elicitation and revision of

user requirements using feedback.

(b) Structural modelling: The UML class diagram

(c) Data Modelling

(d) Architectural design

(e) UX design 1

(f) Content Testing, User Interface Testing, Function Testing, Navigation Testing

-Cycle 3

(a) Further revision of system requirements using feedback.

(b) Behavioural modelling: Use the state diagram and the sequence diagram

(c) System design

(d) UX design 2 based on feedback

(e) Validation/acceptance testing

If you have chosen the Unified Process as your development process, your document may be structured according to the disciplines of the UP and hence look similar to this:

-Inception

-The inception phase should be documented as part of the earlier documents described above.

(b) Establishment of non-functional requirements

-Elaboration (possibly with iterations within):

(a) Requirements elicitation

(b) Architectural design

(c) Scenario-based system modelling (use case diagram, class diagrams)

(d) Data modelling

(e) UX design 1 and testing

(f) Further revision of system requirements using feedback.

-Construction

(a) Behavioural modelling (state diagram, sequence diagram, interaction diagram)

(b) System design

(c) Content Testing, User Interface Testing, Function Testing,

(d) Testing

(e) UX design 2

-Transition phase

(a) UX testing

(b) System testing

The outlines above are just two possibilities for how your documents may be structured. However, it is important that the sequence fits your particular project with all its attributes. Unless your project has unambiguous pre-defined requirements, it is most likely that you will incorporate some form of iteration in your approach. In this case it is important that your documentation evolves and that it demonstrates (to the examiners) the agility of your development approach. Obviously, in a real world project, development is not completed before the system has been deployed and is fully operational in its destination environment. You only have to provide the documentation up to the stage where a programmer can easily translate your design into programming code. You are not expected to do any programming. However, it may well be useful to get an impression of what your application will look like to the user. For this purpose you are expected to create representative screens for your application. These could then also be used for some of your testing.

Note that just because different projects have different numbers of sections/phases, it does not mean that they need to differ in length, or involve different amounts of work. You should also try to avoid unnecessary repetition in your documents. For example you do not need to include exhaustive test cases, but instead it is important that you demonstrate that you know how testing can be carried out by choosing representative examples.

Also note that the examples above differ in some way from the way textbooks describe the processes. This is the case, because it is unlikely that a project that is undertaken by one developer who has little experience will precisely follow a formal software development project. You should decide which sections you need.

##Important activities

Whatever form your documents take, they must include descriptions of how you undertook the activities below. Remember that all these activities can be used in different development processes (agile or more structured), and the order (and the choice of techniques within them) depends on many further factors, including the nature and size of the system to be developed, the preferences of the development team, etc. The list below serves as a guideline, which you can use to check whether your project (somewhere) addresses all important activities:

Define your hardware

Somewhere say something about the hardware your system will be running on. If the system is to be implemented on special hardware, this hardware and its interfaces should be described. If off-the-shelf hardware is to be used, the minimal and optimal configuration on which the system may execute should be set out.

Define your project team

Somewhere you should discuss the skills you think you will need and thus the people you will need to deliver the project. Think also about the people you will need access to for example users to research for requirements.

Requirements elicitation

You have already given an overview of the scope of your system and the stakeholders involved in your project proposal in section 1. Say more about how you are carrying out more detailed requirements elicitation and present your requirements in more detail including:

-A list of requirements

-A set of scenarios of use or user stories

-Any prototypes that may have been developed

Modelling your requirements

Carry out the system analysis tasks (see chapters 8-11). Your documents should describe the functions that the system will perform and any elaborations carried out (i.e. it should present the conceptual model of the requirements of your system). Consider:

-scenario-based system modelling: Use UML models such as the use case model, the activity diagram and the swimlane diagram

-the structure of your system: Create a UML class diagram

-behavioural modelling: Use the state diagram and the sequence diagram

Design of your system

Architecture design

What kind of generic architecture are you using? Provide a holistic picture of the overall structure of your system. What model are you using? The client-server model, the layered model?

Component-level design

Refine your system further within the design phase: provide more details about your system components: define the data structures and outline the algorithms for some representative processes.

Is any database design required? Any details about the nature of the data stored and the structure of a database needs to be specified. You may want to refer back to IS1060 Introduction to information systems to refresh your memory.

Would you consider cloud computing? Are there any web-services which you could include using APIs?

User Experience (UX) design

Design the user interface of your system. Choose techniques that help you to optimize your system’s utility, ease of use, efficiency, etc. Create mockup screens that show what your systems will look like.

Testing your system

Testing is an important part of a software project. Testing needs to accommodate both system verification and validation. The software team must carefully plan the different testing stages, develop a schedule of when they are to be carried out, design the test cases that are needed and eventually collect and evaluate the test results.

Accordingly, the development team must document the order in which system components are to be integrated and the order in which they are to be tested in isolation. Testing methods must also be agreed upon, documented, and carried out where possible.

The purpose of a testing document is to convince the management (in this case, the examiners) that a feasible testing approach has been designed and (where possible) undertaken. You are expected to schedule several stages of your tests. Scheduling is required for unit testing, integration testing, validation (requirements-based) testing and system testing. Most of you will be developing web-based systems, and you must hence consider content, user interface, function, navigation, configuration, security and performance testing.

Obviously, some of these tests are only relevant to certain types of systems. It is your task to choose what is applicable and sensible in the context of your project. For tests that can only be carried out with a fully operational system, you are required to present a test plan, i.e. useful test cases that would yield useful results at a later stage.

You should note that the schedule of testing, and the tests undertaken, will vary depending on the software development process you have chosen, and it is for you to decide when testing should take place.

Your description of the testing should contain the following components:

-a statement of the objectives and success criteria

-a testing schedule with a plan for the order of testing with a justification

-a plan of the testing… [Content truncated to 3000 words]

WRITE MY PAPER