at-blackboard1.comp.glam.ac.ukat-blackboard1.comp.glam.ac.uk/blackboard/CS/CS2S… · Web viewCS2S567 Professional Practice and Employability. Team Based Software Development Workshop

CS2S567 Professional Practice and EmployabilityTeam Based Software Development Workshop

Module Handbook

Version 610 October, 2017

Please report any bugs, typos, omissions, unclear aspects and other weird stuff in this document to: [email protected]

Change Log

Version Date Description1 01/09/2016 Document created2 26/09/2016 Updated tasks for team 1 (removed tasks already done by tutor).

Updated presentation rule: every team member has to contribute to presentation but not everyone has to present

3 04/10/2016 Removed team 11 (disbanded) and references to it.Added possible start-up layout and 'what happen where' graphics to team 2's task descriptionCorrected spelling mistake in Team 11 PRD to 'Team 4 Accounts'

4 23/08/2017 Re-introduced team 11 and general 'new term' spring clean / updating

5 25/09/2017 Final check before 2017/18 roll out, role re-definitions for teams 1, 2 and 14. Started FAQs section

6 10/10/2017 Added Team 16 – IT Support (ticketing system)

Table of Content

1 Aim of the Module.........................................................................................................................41.1 Objectives..............................................................................................................................41.2 What does this all mean?......................................................................................................41.2 Module Setup........................................................................................................................5

2 Presentations.................................................................................................................................62.1 Team Task Presentations.......................................................................................................62.2 Progress Reports....................................................................................................................72.3 Specific Topic Presentation....................................................................................................7

3 Principles (your "Employment Contract")......................................................................................83.1 Fair allocation of individuals' workloads in teams:................................................................83.2 Correct allocation of individual contributions to team effort................................................83.3 Team dynamics / exclusion of team members......................................................................83.4 Ensuring equal opportunities for team members..................................................................8

4 Teams and Team Networking........................................................................................................9

5 Initial Project Requirement Definitions........................................................................................105.1 Team 1: Server.....................................................................................................................115.2 Team 2: Admin /Access........................................................................................................125.3 Team 3: Payroll....................................................................................................................145.4 Team 4: Accounts................................................................................................................155.5 Team 5: Purchasing..............................................................................................................165.6 Team 6: Calendar.................................................................................................................175.7 Team 7: CRM / Invoicing......................................................................................................185.8 Team 8: OurBay...................................................................................................................195.9 Team 9: Holiday booking system.........................................................................................205.10 Team 10: Room booking system..........................................................................................215.11 Team 11: Inventory..............................................................................................................225.12 Team 12: Stock control........................................................................................................235.13 Team 13: Digital Documents................................................................................................245.14 Team 14: Internal Comms....................................................................................................255.15 Team 15: Project Management System...............................................................................265.16 Team 16: IT Support – Job Ticketing System........................................................................27

Frequently Asked Questions (FAQs)....................................................................................................28

1 Aim of the ModuleTo introduce core aspects of legal, social, ethical, and professional issues within the framework of a team project using the AGILE methodology.

1.1 Objectives Legal issues

o importance of project requirement definitions on client contracts o use of copyrighted material /plagiarismo use of IP, securing IP (copyright, patents, trade secrets, trademarks)o digital rights managemento open softwareo software piracyo accessibility

Social issueso social implications of computing in a networked world, e.g. privacy, data snoopingo globalisation

Ethical issues o fair sharing of workload in team, mutual support, whistle blowing (e.g. student not pulling

weight) Professional issues

o work "contract" with studentso Forms of professional credentialingo Time to market and cost considerations versus quality professional standardso professional communications (technical documents, presentations, shared documents, ...)o use of collaboration tools

1.2 What does this all mean?

The Aim and the list of Objectives above look awful: dry, theoretical, boring and not particularly relevant (why do I want to learn that?).

However, in the context of this simulated project you will be applying typical tools that are widely used by employers in the computing industry, e.g. source code control systems and project management / communication systems in the context of the AGILE program development method. These are the real-life 'professional issues' in the Objectives above. Nothing dry and theoretical about them. Tools of the trade - they can even be used for other things than programming, they are transferrable skills.

While you are working on your team project you will naturally encounter and solve many real-life problems such as fairly organising and distributing workload ('social issues'), consequences arising from the company's contract with its customer/client ( 'legal issues') and consider practical problems such as encryption of data and who has access to the data ('ethical issues'). It is all applied and you will be learning practical work skills.

4

1.2 Module Setup

In contrast to other modules this year the content of this module is not primarily technical. Although technology, and especially programming, is an important aspect and although you are likely to learn quite a bit about it, it is only a means to an end here. This end is to introduce you to how computing projects are run in "the real world".

In order to facilitate this we have created a virtual company where you are employed. This company, KrautSoft Ltd., is a software systems house and has just won a major new client contract from Orinoco Ltd., a major B2B1 trading company, for the provision of a large suite of programs to facilitate core parts of its internal operations. As a result of this new contract Krautsoft Ltd. had to hire a large amount of new programmers. You are one of them. Programmers are assigned to project teams, one for each of Orinoco's application programs.

KrautSoft Ltd. operates in a time warp. While the total project duration is 24 days each project day is equivalent to a full University teaching week.

Your lecturers also play roles. Sometimes they will appear as your boss, for example to assess your performance and pay scale (i.e. give you marks). Sometimes they appear as a representative of the client, Orinoco Ltd., to discuss the finer details of the project requirement definitions with project teams. Both roles also exist in projects in the real world - and the views and instructions of the two are not necessarily compatible (another 'professional issue').

1 A B2B company trades only with other companies (Business-to-Business). They rarely have web sites but provide their customers with plugins into their ordering system while in turn using plugins from their suppliers into their own system. This facilitates tight integration and important properties such as just-in-time delivery.

5

2 Presentations

Apart from a one or 2 introductory lectures and a few very brief 10 to 15 minute mini-lectures in-between on some background aspects there will be no lectures. Instead, there are seminars, exactly as in real-life companies. In seminars employees update each other on team progress, receive feedback from others, discuss things and also teach others new skills.

Therefore, over the duration of this module every team will prepare and hold a set of seminar presentations. These not only satisfy a specific technical requirement (e.g. progress reports to inform other teams) but are also intended as training within the module's 'professional practice and employability' remit.

Presentations come in three flavours: Team task presentations Team progress reports Specific topic presentations

2.1 Team Task Presentations

Team task presentations are brief 10 minute Powerpoint presentations followed by a 5 minute Q&A session. These presentations are given during the initial Seminars of the module. Experience suggests that about 8 to 12 slides are adequate to fill the 10 minutes.

Each team member is expected to contribute something to the presentation (and document this in their portfolio). This contribution could be background research, slide design, rehearsal director and main critic, demo program writing, handout production, etc. There can be as many presenters as the team wishes - one, all or any number in between.

The presentations are given for the benefit of the other groups so that these know: The task of the team in general Contact details (e.g. e-mail addresses) of team members so that they can get in touch The specifics of your team's task and their contact points with other teams

At the end of the presentation there will be a 5 minute Q&A session where other teams can ask questions, make suggestions, point out potential problems, etc.

Each slide should have its 'notes' completed. The notes could include: your contact details (notes underneath the title slide) the content of what was said by team members during the presentation response to comments by other teams

After the presentation and following the feedback and comments from other teams. Update your slides and e-mail them to your lecturer for publication on Blackboard.

6

2.2 Progress Reports

Progress Reports are brief 10 minute presentations given during the weekly seminar. Your team will produce 2 or 3 of these reports. The team presentation is then followed by a 5 minute Q&A session where other teams can ask questions, provide suggestions, criticise, etc.

For reporting your team could use Powerpoint slides, projections from a laptop onto screen, handouts, or any other aids that spring to mind.

Each team member should present some of the material.

2.3 Specific Topic Presentation

This is a 20 minute presentation of a specific topic in the style of a lecture rather than a seminar. Your team will hold one of these presentations. The topic may be connected to your team's task but may also be completely different, e.g. introducing the Seminar attendees to AGILE project management.

You can find the topic that has been allocated to your group on the Seminar Allocation Overview Sheet on Blackboard.

As with the other 2 presentation types every team member is expected to contribute to the presentation.

In addition to the Powerpoint slides your team is also expected to produce a Word document on the topic. The document should cover the content of the presentation in a more detailed form so that other teams can theoretically learn all about the topic just by reading the document.

The Word document should be structured like this: A title page (topic, team number and team member names) Table of content Introduction section (background, aim of document) The main body of the content, structured into appropriate sections. Make use of references

to background or specialist material, use graphics, images and tables where appropriate. A summary section, highlighting the most important aspects A 'References' section Where required, an Appendix with additional material

7

3 Principles (your "Employment Contract")3.1 Fair allocation of individuals' workloads in teams:

Taking on tasks within the team is critical but tasks are only allocated by the team if the individual team member agrees (if unsure this could be done on a tentative -> agree basis)

Task allocation follows the "who does what by when" method. If the 'by when' part becomes problematic (i.e. a team member is unable to meet the

deadline) this should be flagged-up as early as possible to the team to resolve it by providing peer help or task re-allocation (caveat: as already said above this must be voluntarily).

Individual team members must not "steal" tasks allocated to other team members (a problem found usually in stronger students) and will get penalised for doing so since "stealing" leads inevitably to disengagement of the "robbed" team member.

3.2 Correct allocation of individual contributions to team effort Code sharing between teams and individuals is encouraged. Both the donor and the receiver

specify and document this in their Portfolios and both are rewarded equally. The actual outcome of a team's effort is not assessed / marked, even if it is a total failure.

Only individual effort is assessed on quality, quantity, timeliness and regularity of, for example:

o issue trackingo bug reportso team task contributiono QA process involvement (report, replicate, respond, resolve)

3.3 Team dynamics / exclusion of team members Teams have no team leader and/or hierarchy allocated, but if a leader emerges in a

democratic way that's fine. Teams must always provide a route back into the team for individual team members who

have disengaged. Conflict resolution is the responsibility of the whole team.

3.4 Ensuring equal opportunities for team members Teams are assembled by the lecturer based on previous year grade point averages

(weighted, with modules of higher relevance to this module having a higher weight) so that students in each team have approximately the same amount of total grade points. This ensures an even ability within in teams. Teams with lower grade points may be allocated technically less challenging tasks (this module is not primarily about technical issues and as outlined in 3.2 above the actual outcome is not assessed/marked).

Attendance at team meetings, module lab sessions, seminars, etc can't be enforced but it should be very clear that it is expected.

Communication and project progress are primarily documented via a professional communications tool (e.g. Trello). Screen shots taken from the tool are useful for providing evidence / verification for individual coursework Portfolios.

8

Team 16IT Support

Team 15Proj. Manag. System

Team 4Accounts

Team 14Internal Comms

Team 1Server

Team 13Digital Documents

Team 5Purchasing

Team 2Access & Admin

Team 6Calendar

Team 12Stock

Team 7CRM / Invoicing

Team 11Inventory

Team 10Room Booking

Team 8ourBay

Team 9Holiday Booking

4 Teams and Team NetworkingThroughout the project your team will have to liaise with many other teams. The above example shows how the HR/Payroll team is connected: all its files are on the central server, its software is accessed via the central access control system and needs a link to the accounts department so that all the pay cheques are booked properly. The staff list maintained by HR is used by the calendar system, required for holiday bookings, internal communications and possibly to populate parts of the CRM system. There are likely to be other connections, too.

9

Team 3Payroll

5 Initial Project Requirement Definitions

As shown in the graph on the previous page the Server and the Access/Admin system are at the heart of the suite of programs. Every team will have to liaise with these two teams but of course also with a several other teams.

The task descriptions or Product Requirement Definitions (PRDs) provided in this document are broad initial outlines provided by the client company and they are not complete. In the real world such descriptions are often the outcome between a first meeting between a company and its clients and even after a project has started these definitions often change due to changing requirements in the client company (called 'scope creep'). The AGILE methodology that will be introduced during this module is well suited to cope with this problem.

A representative of the client, Orinoco Ltd., will be available during the first 3 project days (i.e. Uni weeks 1, 2 and 3) to meet up in your team's office (i.e. the Uni computing lab) in order to finalise the PRD of your programming task.

The need for documentation is not mentioned in the individual preliminary project requirement definitions in this chapter since this need applies to all project teams. All personal team documentations (meeting notes, technical drawings, UML diagrams, Gantt charts, test documents, user manuals, etc) are stored in the coursework Portfolios.

Each team has to document its work, i.e. produce at a minimum a thorough program documentation and a test documentation

Each team has to produce a user manual for the program it has produced

Each team has to produce a team Gantt chart so that other teams can figure out what will be ready by when and coordinate their own progress accordingly.

10

5.1 Team 1: Server

This is one of the two core systems (the other one being the Access/Admin system produced by team 2). Every other team will have to liaise with this team.

This team's preliminary tasks (in order of time importance) are:

1. Research and implement a way in which the programs of all other teams can be deployed together

Initially we keep things simple: Each team produces its own executable and reads/write all data its program produces locally to a data file. This allows teams to make progress while Team 1 explores a more advanced solution.

Possible solution alternatives might be: The entire suite of all programs and data is held on a networked drive. So,

not really a "server" in the classic sense. Users have access to this drive on their own workstation PCs. This is probably the technically most simple solution (although it might be a bit tricky or impossible to network a drive on a USW lab PC as they are fairly locked down. Workaround: use your own laptop, eduroam and something like GoogleDrive or so).

Creation of a server and then access via FTP or perhaps an OwnCloud (or NextCloud) installation. In both scenarios data could be stored either as files or in a database.

A/N Other - your choice

2. Once a basic system is in place roll it out to all teams. Remember that you have to provide to all other teams clear instructions and/or example code how to use your setup.

3. More demands and requirements will now come in from other teams, e.g. provide a program for managing password protected access to only parts of the programs and/or data.

Team 1 has one additional task: ArbitrationIf there is a non-technical dispute within a team (e.g. team members permanently absent or the team can't agree on who does what) or if different teams have a dispute between them that they can't resolve on their own then these teams will first ask team 1 for arbitration in the matter. Only if the decision by team 1 is deemed not to be acceptable by other teams or if team 1 feels that it can't or shouldn't make a decision the matter is referred up to the boss of Krautsoft Ltd. (i.e. the lecturer).

Technical disputes and decision making is delegated to team 2.

11

12

5.2 Team 2: Admin /Access

This is the second of the 2 core systems (the server system being the first). Every other team will have to liaise with this team. The system developed by this team is regulating access to the programs of all other teams (and itself) and will be used by the company's management, e.g. for granting certain access rights, setting salary levels, etc. Think about how access can be protected. Should it be encrypted? Which interactions will require confirmation by a second or third person?


1. Setup a simple overall user interface from which all other team programs can start. To begin with this could be a single window with a button to launch each team's program. A possible layout could be something like this:

2. Inside this user interface create a program that assigns and controls rights for each different user or entire user groups, i.e. which user is allowed to do what in each team's program. You will get a list of users and their roles from the server folder of team 3, Payroll. You will have to talk to all other teams in order to find out what the user access rights should be.

3. The user access rights could be passed to the programs called from your overall user interface as an argument string into Main or you may want to provide a class that the programs of all other teams must incorporate and that reads or creates the access rights elsewhere.

4. You may be asked by other groups to provide particular services. For example, team 6 (Calendar) might require an Owncloud or Nextcloud installation that provides

13

CalDAV functionality and team team 7 (CRM/Invoicing) may want CardDAV functionality for its Customer Relationship Management (CRM) system. Work with team 1 to implement these requirements on the server (or whatever backbone they design).

5. Real men don't do backups. And real men don't cry if they have lost data as a consequence. So you better make sure that nobody starts screaming at you because team X has accidentally deleted data of team Y. Research and design a good backup system and implement it. Again, you may need to work with team 1 to implement this

More demands (e.g. provide a program for managing the above password protected folders and access rights) may come from the client representative and/or from the other teams.

Team 2 has one additional task: Making technical decisions. This task falls to team 2 since it is liaising with all other teams of the project and it is therefore likely to be the team with the best overall inter-connections between teams. Generally, the requirements of projects such as this one are always driven by the customer. However, while there is usually a customer representative involved in such projects this person can't be present permanently. When the representative is absent or unavailable team 2 will therefore be charged with making preliminary technical decisions for the customer (and confirm this with the customer afterwards).

Non-technical disputes and decision making is delegated to team 1.

14

5.3 Team 3: Payroll

It is likely that most teams (but probably not all) will have to liaise with the team that is implementing the Payroll program since this program will maintain the list of company employees and their respective roles, e-mail addresses, etc.


1. Setup a list or database of company employees (names, e-mail addresses, bank details, etc). This could be a real database or just a cleverly designed list or text file. Up to you. Keep this flexible as other teams may ask you to add more information.

2. Provide an access facility to these data for other teams who may need them for their own programs. This will require handling of access rights so you will have to liaise with team 2: Admin / Access. Not every team or employee will be allowed to see, edit, add, delete data and certain changes will have to be signed off by management (ie. the team 2 system).

3. Set up a facility to perform monthly pay runs so that every employee will get paid in time. Bear in mind that people might start halfway through a month so they may not receive the full pay.

4. Research the legal requirements. If the company has £100 to pay an employee how much of this goes to HMRC (the so called 'employers contribution'), how much apprenticeship levy is deducted and has to be paid and what is the employer's workplace pension contribution this year? From what is left you have to deduct PAYE. For that you need the employees tax code (supplied by HMRC). You need to calculate National Insurance as well and deduct it. Is the employee in a pension scheme? In that case you have to deduct these contributions before calculating tax and MI and pay the pension provider. This is tricky and the rules and amounts change from time to time. How can you make the system flexible enough to cope with such change?

5. Team 4 (Accounts) will have to receive the data generated by each payroll run.6. Employees may claim expenses (travel, accommodation, etc) and that has to be re-

imbursed via the pay run - but expenses do not attract tax, NI or pension payments.7. The unions may negotiate a pay rise, backdated or at a particular date or staged. This

needs to be handed by the system as well.8. Monthly payslips for each employee (and their P60s at the end of the year) should

be stored with team 13 (Digital Documents) so that employees can see and/or print them out.

More demands may come from the client representative and/or from the other teams.

15

5.4 Team 4: Accounts

Bean counts R'us. This system has connections with the programs of many other teams, e.g. team 3 (Payroll), team 4 (Purchasing), etc.


1. Research how a typical accounts system is set up. For this project start simple, i.e. that it can handle the requests coming from other teams such as purchasing, payroll, etc. Figure out a good interface system (perhaps write an AccountsAccess class that other teams can use).

2. Slowly expand so that the system so that it can handle requirements external to the company, especially:

a. payments to and from HMRC (PAYE, NI, VAT, corporation tax)b. payments from customersc. payments to suppliers

3. Think about managing cash flow. Don't pay invoices (data transmitted from the system of team 5 (Purchasing)) before it is really necessary, i.e. payment terms of the supplier. But then pay promptly, you don't want to be in the bad books.

4. Setup a management information system that provides at any moment in time standard data on:

a. the current balance sheetb. payroll information (this month, year up to current month, total year

projection)c. sales information (this month, year up to current month, total year

projection)d. Profit and loss account between selected datese. Cash flow forecast

A standard set of these data sets should be created automatically and stored with the system created by team 13 (Digital Documents).


16

5.5 Team 5: Purchasing

The nice job. Spending other people's money. This team will have to work closely with team 4 (Accounts) to define purchasing categories (hardware, software, consumables, services, import duty, ...). You will also keep in touch with team 11 (Inventory) so that purchased hardware can be registered and team 12 (Stock control).


1. That up a user interface that allows company employees to file purchase requests (what item, amount, price, ...) There should be a list of suppliers they can order from and a provision to ask Purchasing to add a new supplier to the list.

2. Listed suppliers may provide discounts. These have to be automatically taken into account when placing an order.

3. Purchase requests by employees have to be authorised by company managers (liaise with team 2: Access & Admin) before the order can be sent out.

4. Once authorisation has been received. The system then has to order the goods (option to print order or send electronic orders via e-mailed PDFs).

5. When employees or the Stock Control (team 12) receive the goods they must notify Purchasing that the goods have arrived and are complete / undamaged. Since they will always forget the system should start sending reminders at a certain time after ordering (via team 14: Internal comms).

6. Once goods have been confirmed as received and OK, team 4 (Accounts) needs to know so that they can pay the invoice. However, some goods have to be paid in advance (e.g. flights, hotel, travel, ...) and some goods may need to be returned because they are damaged, not working or they were ordered in error.

7. What happens when goods are not arriving? There must be a way of checking if estimated delivery times are exceeded so that Purchasing can take action.


17

5.6 Team 6: Calendar

This team provides calendars for individuals and groups.


1. Create a calendar system that for each employee or group can handle (setup, edit, delete) several sub-calendars such as private calendar, work calendar and team calendar but also subscribe to the central company dates calendar, other team calendar, etc.

2. Who will have access to whose calendar (e.g. everyone to the central comapny calendar but not to the private one). Talk to team 2 (Access & Admin) about access rights.

3. Draw-in dates/times from other teams, e.g. team 9 (holidays), team 10 (room bookings), team 15 (project planning), team 5 (purchasing , i.e. when goods are due to arrive) but also provide dates to all teams that need them.

4. The system should allow employees to invite for events (and others to accept or reject them)

5. Study a few calendaring systems and the options they provide. Consider implementing calendar syncing. For this you could ask team 2 to provide, for example, CalDAV functionality on an Owncloud or Nextcloud installation.


18

5.7 Team 7: CRM / Invoicing

Customer Relationship Management (CRM) systems are "managing a company's interaction with current and potential future customers. The CRM approach tries to analyse data about customers' history with a company, to improve business relationships with customers, specifically focusing on customer retention, and ultimately to drive sales growth" says Wikipedia.

At its heart the CRM is a sort-of database but in contrast to this it is not just a passive dump of data. It actively manages relations with customers. In a way it is the counter-piece to some of the functions of a purchasing system (see team 5 (Purchasing)).


1. Set up the underlying customer database functionality. This does not have to be a "proper" database. It may in fact be better to code data structures to hold the information. Visual Studio's Linq functionality may also be helpful. Explore the alternatives and decide.

2. Implement the invoicing functionality to customers. Invoices are sent when the system from team 12 (Stock control) signals that goods have been sent out to customers. Invoices may have to be printed or could be e-mailed as PDFs.

3. Goods that are being sold need a price. Make sure they can't be sold under the purchasing price (speak to team 5(Purchasing)). Also, customers may have negotiated discounts and VAT needs to be added.

4. The system of team 4 (Accounts) has to be notified that an invoice is pending.5. Reminders should be sent automatically after 30 days (company standard payment

terms). And after another 10 days final reminders. After another 10 days a message should be sent to senior management via the system of team 14 (Internal comms) and the customer blacklisted.

6. Implement CRM functionality for the Marketing and Sales Departments. Research such systems and provide the key functionalities they provide.


19

5.8 Team 8: OurBay

Initially an internal eBay system but it could eventually be rolled out to all customers of the company. Note that it is not an online retailer but a Business-to-Business company. These do rarely have web shops and such like but instead provide plug-ins into their ordering system to the customers and in turn receive such plugins from their suppliers.


1. Provide a system for the company's employees to buy goods from their own company. Obviously at a nice discount but also obviously not in unlimited numbers. Speak to team 2 (Access & Admin) who can set these discounts and amounts. The list of goods on offer is available from the system provided by team 12 (Stock control). Once items have been purchased inform the system of team 7 (CRM/Invoicing) and team 12 (Stock control) about the purchase.

2. Once this system is working internally provide an API for inclusion into the systems of the company's customers. To make it easier for these customers and also in order to test the system produce a stand-alone example/demonstrator application.


20

5.9 Team 9: Holiday booking system

In every company the booking holidays inevitably leads to tensions. The system to be developed by team 9 is supposed to minimise these.

Since this team is only loosely coupled to other teams2 there is, with the exception of task 1 below, no particular urgency to finish one aspect of the system earlier than others. The preliminary requirements below are therefore listed in no particular order:

1. Negotiate, as soon as possible, an interface with team 6 (Calendar) so that holidays can be shown in individual's calendars.

2. Enable managers to set fixed company holiday dates (e.g. Easter, Christmas, etc)3. Drag standard UK bank holiday dates from the internet and use them in the system4. Allow managers to ban certain dates from being bookable (e.g. if tight deadlines

require all hands on deck)5. Ensure that each department always has a certain minimum staff coverage (set by

management)6. Allow employees to request holiday. Leave requests have to be signed off by the

employee's respective line manager. Only the boss has no line manager and can do what she pleases (husbands know this). The system of team 3 (Payroll) will tell you who manages whom.

7. Allow managers to see the holidays of the people they manage so that they have an overview and can manage accordingly. The boss, of course, sees all.

8. Holiday bookings should be flexible, i.e. it should be possible to change dates or to cancel a holiday if necessary. Again, changes have to be signed off by the line manager.

9. An anonymous (no names) overview of all holidays taken should eventually be created automatically whenever a change occurred and stored with the system created by team 13 (Digital Documents).

10. Ideally the system should inform employees in good time before the end of the year that they are in danger to lose holiday days if they don't book soon. Only a management defined amount of days can be rolled over to the next year, the rest is lost and is not compensated in pay.

11. Allow for the booking of sick leave and maternity/paternity leave. In such cases inform team 3's system (Payroll).


2 You will have to liaise with Team 1 (server) for the underlying IT basics and Team 2 (Access System) to get the information on access rights but few teams other than team 6 (Calendar) are likely to rely on your output.

21

5.10 Team 10: Room booking system

The client, Orinoco Ltd., has a number of rooms for meetings with customers, staff performance reviews and other clobberings, office parties, seminars, etc. To avoid conflict, these rooms have to be booked in advance.

Since this team is only loosely coupled to other teams3 there is, with the exception of task 1 below, no particular urgency to finish one aspect of the system earlier than others. The preliminary requirements below are therefore listed in no particular order:

1. Negotiate, as soon as possible, an interface with team 6 (Calendar) so room bookings (e.g. for meetings) show up in individual's calendars.

2. If a room is booked by a member of staff then another member of staff should be able to ask the 1st booker to change the booking.

3. Line managers (liaise with team 3 (Payroll) to access the company hierarchy) can over-ride a booking but the system must inform the first booker immediately if that happens.

4. Double-booking is not possible.5. When booking rooms for seminars and meetings it should be possible to invite other

members of staff (list from Payroll). It should be possible to create groups (e.g. all members of the sales team). Invitations should show up on the internal communications system produced by team 14 and can be accepted or declined by the invited person. Accepted invites are then shown on the invited person's own calendar (team 6).


3 You will have to liaise with Team 1 (server) for the underlying IT basics but few teams other than team 6 (Calendar) are likely to rely on your output.

22

5.11 Team 11: Inventory

Every company has assets such as buildings, machinery, office equipment, software licenses, etc. These assets have to be represented in the company's balance sheet. Trading stock held by the company (see team 12's task) is not part of the inventory.


1. Create an first basic inventory system that holds the name type and value of assets. Agree on a way to transmit this information to team 4's system (Accounts).

2. Liaise with team 5 (Purchasing) so that new assets which have been bought can be entered into the system as automatically as possible.

3. Create the possibility to dispose of assets (damaged, old, rubbish, etc)4. Create an overview inventory list for show in the company's management information

system (team 13 (Digital Documents))5. Things grow older. In company terms this is called depreciation. Depreciation causes a

nominal loss which can be deducted from the company's profits and thus reduces tax. It is also a good way to find out when assets have to be replaced because they are getting on a bit. To implement this you have to:

a. research depreciation rules (which assets can be depreciated by how much and when can they be written off completely)

b. implement these rules (there will be different ones for different asset types (buildings, vehicles, office equipment, etc)

c. calculate depreciation at regular intervals (individually for each item, depending on purchase date)

d. Inform the system of team 4 (Accounts) whenever the total value of inventory has changed.

6. Software licenses have to be reviewed at regular intervals. Inform team 5's system (Purchasing) that a renewal is due. Purchasing in turn will inform you about the renewal terms when software is bought and has been renewed. If a renewal notice has not been sent (i.e. Purchasing forgot to order it) send them a reminder via the company's internal communications system provided by team 14.

7. Some assets need to be checked for safety at regular intervals (e.g. electrical safety tests, mechanical tests for manufacturing tools, MOT for company vehicles, etc). Automatically generate messages to the company's estates services via team 14's internal communications system.


23

5.12 Team 12: Stock control

The programme to be produced by this team handles the company's stock.


1. Provide a list of goods the company provides to its customers. This list needs an interface to the system of team 8 (ourBay) so that customers can browse and purchase.

2. React to orders received by the system of team 8 (ourBay). Team 8 or team 7 (CRM/Invoicing) will have the address information to be printed on the parcel labels for sending out.

3. When goods have been sent out team 7's invoicing system needs to know so that it can produce the invoices.

4. Inform the system of team 5 (Purchasing) when goods have reached a critical low level so that that system can order more.

5. Produce an interface to team 4 (Accounts) so that the current stock value can be reflected in the company's balance sheet.

6. Identify goods that are close to their sell-by date so that these goods can be shifted in promotions. Promotional reduced prices are reflected in a lower stock value (important for team 4 (Accounts) and team 8 (ourBay)).

7. If goods are past the sell-by date take them off stock, correct stock numbers and make sure this information is sent to the correct external systems.


24

5.13 Team 13: Digital Documents

This system will represent the company's knowledge base.

The team's preliminary tasks (in order of time importance) are:

1. Produce style guides (may be MS Word templates?) for the standard documentation tasks every team has to perform. In particular:

a. program documentationb. test documentationc. user manual d. Team Gantt chart (A template Excel spreadsheet will do to start with, ask the

client representative for details. Later may be use the system created by team 15 (Project Management)

2. Create an overview Team Networking document visible to all teams (similar to the one shown in chapter 4 of this document) that shows all interconnections between teams. How could this been done intelligently so that it does not look over-crowded? An active document like EasyJet's flight route map perhaps? Go, figure.

3. Create a storage system (folder hierarchy?) on the server. Discuss this with team 1 (Server). Perhaps Owncloud or Firstloud provide a good way to do this. Consider access rights (team 2 will advise), backups and restore, version control of documents, etc. How are documents uploaded, displayed, downloaded, updated? What about encryption of sensitive information?

4. Liaise with team 3 (Payroll) to create the facility for storing payslips and P60 forms (end of year forms required by HMRC)

5. Liaise with team 4 (Accounts) to discuss the requirements for the management information system.


25

5.14 Team 14: Internal Comms

The task of this group is to come up with a new inter-company communications system that intelligently combines:

instant messages (immediate display on the recipient's machine) delayed display & responses (such as e-mails) automated and semi-automated notifications (e.g. team 12's stock control system

informs teams 5's purchasing system that certain goods need to be re-ordered) Features such as to-to lists, wiki-style documents (may need to talk to team 13

(Digital Documents)), milestone management (may need to talk to team 15 (Project Management))

In contrast to other teams this team is given a free reign to dream up a new approach. Since this team is also loosely integrated into the network of other teams the progress of other teams is not dependent on its progress. A good deal of time can therefore be invested into background research and a thorough design.

However, it is possible that immediate demands may come from the client representative and/or from the other teams (e.g. from team 10 (Room booking invites)).

Team 14 has one additional task: Setting-up an inter-team communication system This task has nothing to do with the client, Orinoco Ltd. or the system to be developed for the client (e.g. the 'Internal Comms' task above).This task is for internal use inside Krautsoft only: you will research, implement and maintain a Trello based communication platform for use between all Krautsoft teams that tracks the progress of the overall project.

26

5.15 Team 15: Project Management System

To clarify: this task is not to manage the other Krautsoft teams or to build a system for Krautsoft. This is task is concerned with creating a project management system for the client company, Orinoco Ltd.

Like every other company, Orinoco is constantly running a string of smaller and larger projects (this CS2S567 team project is one of them).


1. Negotiate an interface with team 6 (Calendar) so that events generated by the project management system can be incorporated into individuals' calendars.

2. The AGILE methodology is not only useful for programming projects but can be rolled out generally. Orinoco wants you to create a management system that reflects this methodology. Therefore:

a. do background research on the AGILE methodology. You may want to link-up with teams 7, 8 and 9 since they are each going to hold Seminars on this topic.

b. implement facility that can hold project documents such as 'user stories' (liaise with team 13 (Digital Documentation))

c. implement a facility that handles project communications (liaise with team 14 (Internal Comms)

d. create a simple Gantt charting tool to time 'sprints'e. code a tool to create and manage 'burndown charts'

The above list is not complete but the minimum requirement. More demands may come from the client representative.

27

5.16 Team 16: IT Support – Job Ticketing System

Since Orinoco is a large company with multiple IT systems its IT department somehow has to manage and organise work requests it receives from users.


1. Do background research into existing commercial ticketing systems (e.g. Zendesk). How do these systems work, what functions do they provide, etc.

2. Liaise with team 14 (Internal Comms) on how users may get informed about work progress and how IT staff can communicate with users.

3. Discuss with team 15 (Project Management System) if it makes sense to connect your ticketing system with their system for larger jobs (e.g. not for fixing a broken hard disk on a user PC but for large undertakings such as installing a new server farm).

4. Start implementing a first version of the ticketing systems where: a. a user can log a work requestb. the user gets a receipt (via Internal Comms)c. the work requests gets prioritised (low, medium, high and emergency

importance) and assigned to one or more members of IT staffd. IT staff and users can enter into a logged dialog (e.g. IT staff can contact users

asking for further information or clarification and users can respond, users can add additional info or cancel the work request – some IT problems sometimes just “go away”)

e. IT staff can inform users of progress and can close the ticket once the work has been completed.

The above list is not complete but the minimum requirement. You will also have to work with teams 1 and 2 in order align your ticketing system with the underlying backbone and workflow. More demands may come from the client representative.

28

Frequently Asked Questions (FAQs)

Q: What programming language shall we use?A: Any language you like provided:

1. it can be used on a standard Windows system without too many dependencies on other external programs or weird setups

2. It can integrate with the overall system all other teams are building (if in doubt, negotiate with team 2)

Q: What is the difference between Krautsoft and Orinoco?A: Make sure that you are aware that

1. Krautsoft is the company that builds the system described in this document for Orinoco. Krautsoft is the supplier, Orinoco the customer.

2. You are all employees of Krautsoft not Orinoco.3. The 16 Krautsoft teams building the system for Orinoco are not the users. (The teams

occasionally simulate being the users, e.g. when they do testing but the real end users are the employees of Orinoco.)

29