Enterprise Project

Managing and Documenting a Project

🎯 (EC-12-08, EC-12-09)

📌 Describe the tools and processes used to manage and document the development of an enterprise system

• problem definition
• time and resource management, including Gantt charts
• an iterative approach
• production process and technical skills
• testing and evaluation

NESA defines project management as “the process of planning, organising, controlling resources, monitoring timelines and activities, and completing a project to achieve a goal that meets identified criteria” (NESA syllabus glossary). Project work in this focus area follows the design and production process: identifying and defining, researching and planning, producing and implementing, and testing and evaluating. Each stage has its own tools. The table shows where each one appears in these notes, so you can see the whole project before the detail.

Problem definition

A problem definition is a short, precise statement of the problem the project will solve. It is written first because every later decision, from which diagram to draw to whether the finished system counts as a success, is judged against it. A good one describes the problem, not the solution: “build an app” is a solution, whereas “members cannot see which courts are free, so double bookings happen” is a problem. It also says who is affected, what the project will and will not cover (its scope), the constraints (time, money, skills, technology) and measurable success criteria. NESA’s teaching advice says students identify “a real-world problem of interest and develop a solution”, so the definition must come from a real need, confirmed with the people who have it.

Check a problem definition with four questions. Does it name a real problem rather than a product? Could a stranger tell who is affected? Can each success criterion be tested with a yes or no? Is the scope small enough to finish in the time available? If the answer to any is no, tighten it before you plan anything else.

Time and resource management, including Gantt charts

Time management means estimating how long each task will take, putting the tasks in a workable order and checking progress against the plan. Resource management means making sure the things the project needs are available when they are needed: people and their skills, hardware and software, data, money and each person’s hours. The main tool is the Gantt chart. NESA (Course Specifications, p.12) describes it as displaying “each of the component tasks in a proposed system development on an estimated timeline”, with self-explanatory task names, the time needed for each task and its dependent tasks, a dated time scale and marked milestones. Its second example adds team members and the percentage complete, and says charts “should be regularly updated during development to reflect actual versus estimated times for tasks”. The notation is explained in the Course Toolkit; here we apply it.

Reading a Gantt chart for problems is as important as drawing one. Ask which tasks are late or behind (compare the shaded share of a bar with how far along the time scale the status date is), which tasks depend on them, and which people are double-booked or idle. The longest chain of dependent tasks decides the earliest finish date, so a delay to any task on that chain moves the handover. A task off that chain has some slack. In ClubHub the chain runs database, stock screens, integration, testing, trial, handover, so Ben’s slip matters; a slip in Ana’s data flow diagram would not.

An iterative approach

NESA’s teaching advice describes project work as “an iterative process that builds on a systematic approach to problem identification, research, problem-solving, prototyping and evaluation”. Iterative means the team repeats a cycle of designing, building, testing and reviewing, improving the system a little each time, instead of expecting to get everything right in one pass. The design and production stages are not a one-way street: evidence from testing sends the team back to change the design, and a change to the design means the plan, the diagrams and the tests are updated too.

Iteration keeps a project honest because the client sees something early. In ClubHub the team did not wait until the end to find out whether members could use the booking screen:

Each loop is recorded in the process diary and the Gantt chart is adjusted. Iteration is a habit that any development approach can use, and it is central to agile and prototyping (see Choosing a Development Approach). A common mistake is to iterate without a definition of “good enough”: return to your success criteria to decide when to stop.

Production process and technical skills

NESA’s glossary defines producing as “actively realising (making) designed solutions, using appropriate resources and means of production”. The production process is the sequence of steps that turns the design into a working system. For ClubHub it runs: set up the shared workspace and a backup routine; build the database tables from the schema and data dictionary; build screens from the approved storyboard; add validation so bad data is refused; connect the parts; and keep a written record of every change so that the work can be repeated, fixed or handed over.

Doing that takes technical skills, and a good team audits them early, because a missing skill is a risk. If nobody can do something, the team can train someone, share the task or (see approaches) outsource it.

Technical skills sit beside working skills such as communicating with a client, planning your own time and giving useful feedback. Both kinds are evidence in a process diary. When you write about a project, name the skills you used and where you were stretched.

Testing and evaluation

Testing and evaluation are not one step at the end. They run through the whole project, and they are how iteration decides what to change. Testing checks whether something behaves as expected. Evaluation, in NESA’s glossary wording, is to “make a judgement based on criteria; determine the value of”, so the criteria come from the problem definition: you evaluate ClubHub by asking whether it meets each success criterion.

Part 4 of these notes covers the detail: verifying and validating a system, test data and maintenance. The Toolkit lists NESA’s six testing methods in Methods for Testing a System.

The Changing Nature of Enterprise

🎯 (EC-12-06, EC-12-07)

📌 Explain the effect of the changing nature of enterprise on the development of projects

• offshore development
• working remotely
• freelance work
• enabling the growth of start-ups

Digital tools have changed where and by whom enterprise systems are built. Fast networks, cloud services and online collaboration tools mean a project team no longer has to sit in one room, work for one employer or even live in one country. NESA asks you to explain the effect of four changes on the development of projects. To explain is to give causes and effects, so for each change the notes below say what it is, how it changes the way a project is planned and built, the benefits and the risks, and how a team manages them. In ClubHub’s case the team is local, so each change is illustrated by asking “what if the club had done it this way instead?”.

Offshore development

Offshore development means having software or systems built by a team in another country. It is not the same as outsourcing, which means paying an outside organisation to do the work wherever it is; a company can offshore work to its own overseas office, and it can outsource to a firm down the road. Enterprises offshore to reach skills that are scarce at home, to lower the cost of development and to keep work going across time zones.

Effect on the project. The team must plan for distance. A large time difference leaves few overlapping working hours, so meetings are scheduled, decisions can take a day longer and the Gantt chart has to allow for the delay. Requirements must be written clearly enough to be understood without a conversation, which pushes teams towards detailed specifications, prototypes and written acceptance tests. Differences in language and culture can cause misunderstandings that show up as defects late in the project.

Benefits: access to specialist skills, potentially lower costs, extended working hours and more capacity. Risks: communication delays, quality that is harder to check, dependence on one supplier, and legal and security issues. Under the Privacy Act 1988 (Cth), an Australian organisation that discloses personal information to an overseas recipient must generally take reasonable steps to ensure the recipient does not breach the Australian Privacy Principles (APP 8, cross-border disclosure; see the OAIC guidelines), so where member data is stored and who can see it must be decided early. Ownership of the code, confidentiality and how disputes are resolved belong in the contract.

Managing it: agree overlap hours, use a shared plan and task board, split the work into small deliverables with acceptance tests, review code regularly and keep documentation up to date so knowledge is not locked up in another country.

Working remotely

Working remotely means team members work from home or another place away from a shared office, connected by video meetings, messaging, cloud storage and shared documents. Remote working is possible because the project’s materials (documents, diagrams, code, test results) are digital and can be shared online, as the Networking Systems notes explain for connectivity and work.

Effect on the project. The team can recruit from a wider area, and members save travel time, but the plan has to replace the conversations that happen by chance in an office. Teams write down decisions, keep a shared Gantt chart and process diary, hold short regular check-ins and rely on tools such as version control so that two people do not overwrite each other’s work. Progress is judged by finished tasks rather than by who is seen working, so tasks need to be small and clearly defined.

Benefits: a wider pool of talent, flexibility, lower office costs and continuity when people cannot travel. Risks: weaker communication, isolation and unclear expectations; and security, because company data now sits on home networks and personal devices. Managing this uses the controls in Cyber Risk Management: multi-factor authentication, encrypted connections, access only to the data a role needs, and clear rules about which tools may hold personal information. A ClubHub example: if Ben works from home on the member table, he should use test data, not real members’ details.

Freelance work

Freelance work is work done by a self-employed person who takes on tasks or projects for different clients, rather than being an employee. Freelancers are used for particular pieces of work such as an interface design, a database build or testing.

Effect on the project. A team can add a missing skill for exactly as long as it is needed, and the project plan can be built around specialist tasks. The team must also plan the handover: a freelancer’s knowledge leaves when the contract ends, so the work has to be documented and the deliverables clearly defined (what will be delivered, when, to what standard, and for what payment, often by milestone). Availability is a scheduling risk, because a freelancer may have other clients.

Benefits: flexible cost, specialist skills, fast start. Risks: availability, uneven quality, dependence on one person, and ownership of the work. In Australian law the creator of a work is generally its first owner under the Copyright Act 1968, so a client who wants to own or freely modify a freelancer’s code needs the contract to say so in writing, and should get legal advice on the wording. For ClubHub, the club might hire a freelance graphic designer for the logo; the agreement should state that the club may use and change it.

Enabling the growth of start-ups

A start-up is a new enterprise, usually built around an idea for a product or service, that aims to grow quickly. Cloud computing, software as a service, open-source software and app stores have lowered what it costs to begin, because a start-up can rent computing power by the month instead of buying servers, and can add offshore, remote and freelance help without a large payroll. The Networking Systems notes discuss what makes a start-up succeed in Start-ups and success.

Effect on the project. Start-up projects tend to be short, iterative and focused on getting something in front of users quickly. A common tactic is to build a minimum viable product (MVP), the simplest version that solves the core problem and lets the founders learn from real users, then improve it in cycles. Requirements change often, so agile approaches and prototypes are popular, and money is limited, so the budget and the time-and-resource plan are tighter.

Benefits: lower entry costs, speed and the ability to test an idea before committing much money. Risks: running out of money, depending on other companies’ platforms (a price rise or a change of terms affects the whole business), neglecting security and privacy because of pressure to launch, and difficulty scaling a quickly built system. A ClubHub example: a start-up could turn ClubHub into a service for many clubs; its first job would be a minimum viable product for one, using hosted cloud services rather than buying hardware.

Tools for Design and Development

🎯 (EC-12-08, EC-12-09)

📌 Investigate tools that support the design and development of an enterprise system

• online collaboration
• time/task action plans
• process diary, including ongoing evaluation
• budget
• system flowcharts
• data flow diagrams
• decision trees

To investigate a tool is to ask what it is for, what it costs the team to use, where it falls short and when it is the right choice. The seven tools below each answer a different question about the ClubHub project. Read the comparison first, then the detail; the closing judgement says which ones a small team could not do without.

Online collaboration

Online collaboration tools let a team share and work on project materials without being in the same place. The main kinds are shared document and file storage (with version history so an earlier copy can be restored), messaging and video meetings, task boards that show each task as a card moving from “to do” to “done”, and version control for code and other files that lets several people change the same project and merge their work. NESA defines collaborate as “working with others towards a shared goal, through a variety of modes of communication”, and these tools are those modes.

Criteria for choosing. Can everyone reach it, including on a phone? Does it keep version history? Can access be limited by role? Where is the data stored and who can read it? What does it cost? ClubHub’s team chose a shared folder with version history, a task board for weekly tasks and a messaging group for quick questions. Judgement: online collaboration is essential, but only with rules: agreed file names, one owner per document, and no real member data in chat messages.

Time/task action plans

A time/task action plan is a short list, usually for a week or a work session, of the tasks to be done, who is responsible, when each is due and its status. It sits beneath the Gantt chart: the Gantt chart shows the whole project and its dependencies, the action plan says what each person does this week. It is quick to write and easy to review at a check-in.

An action plan does not show that “Build stock screens” cannot start until the database is finished, and it does not show percentage complete on a time scale. Use it with the Gantt chart, not instead of it. Judgement: a small team gets the most from a Gantt chart for the whole project and an action plan for each week.

Process diary, including ongoing evaluation

A process diary (or log book) documents the progress of the project as it happens. NESA (Course Specifications, p.13) says entries made by team members at regular intervals should include the date, the person making the entry, progress since the last entry, tasks achieved, stumbling blocks or issues and how they were managed, possible approaches for upcoming tasks, reflective comments and resources used. The layout of each item is in the Course Toolkit. Ongoing evaluation is the habit of judging your work against your success criteria as you go rather than only at the end: the reflective comment in each entry is where you do it. Ongoing evaluation is why a diary is more than a record; it changes what the team does next.

Judgement: the diary is the cheapest and most useful tool on the list, because it records the reasons behind changes to the Gantt chart. Its weakness is that it is only as good as its entries: a diary written the night before it is due is not ongoing evaluation.

Budget

A budget is a plan of the money a project will need and where it will be spent. It answers a feasibility question (“can we afford this?”) and, once the project is running, a control question (“are we within what we planned?”). List every cost you can identify, estimate each one, add a contingency (an amount held back for costs you did not foresee), and compare the total with the money available. Then keep an actual column and compare it with the planned figure as invoices arrive. All prices below are invented for teaching; a real budget uses quotes.

Subtotal    =SUM(B2:B6)     gives 690
Contingency =B7*0.1         gives 69
Total       =B7+B8          gives 759
Unallocated =800-B9         gives 41

This is the spreadsheet method from the Course Toolkit. Notice what the budget does not show: student time. ClubHub’s team is not paid, but a real project would cost its people’s hours, and a good budget records them even when nobody is invoiced, so the client can see the full value. Judgement: a budget is essential if any money changes hands. If a cost is found to be more than planned, the response is to reduce scope, raise more money or use the contingency, and the decision belongs in the process diary.

System flowcharts

A system flowchart shows the main processes and devices in a system and how data moves between them. It answers “what is this system made of?” at the level of hardware and stored data. The NESA symbols (Course Specifications p.7) are the paper document, process, direct access storage, online display, manual operation, telecommunications link, online input, magnetic tape and cloud; the Toolkit has the key. Arrows show the direction of data, not the order of steps, and no flowchart symbols (terminator, decision) are mixed in.

Data flow diagrams

A data flow diagram (DFD) shows what data moves between the people outside a system, the processes inside it and the places data is stored. It says nothing about screens or hardware, which is why clients understand it. NESA’s symbols (Course Specifications pp.4–5) are the circle (process), open-ended rectangle (data store), closed near-square rectangle (external entity) and labelled curved arrow (data flow); see the Toolkit. A Level 0 diagram is an overview of the entire system: one process, all the external entities and no data stores.

How to derive it. (1) List who or what supplies data to the system or receives data from it: these are the external entities (members, the club secretary, the canteen coordinator, suppliers). (2) Write the single system process in the middle. (3) For each entity, list what it sends in and what it gets out, and name each flow with a noun phrase describing the data (“Booking request”, not “Book”). (4) Give every arrow a head and a label, and draw two-way exchanges as two separate curved arrows.

Decision trees

A decision tree shows how a series of yes/no or multiple-choice questions leads to an outcome. NESA’s examples (Course Specifications p.8) use rectangles joined by labelled branches, and each path ends in a final action; see the Toolkit. A decision tree is the clearest way to record a business rule and to check it is complete. To build one: write the outcomes the system can produce, work out the questions that separate them, put the most important question at the top and label every branch. Then test every path with an example.

Choosing between the tools

A small team rarely uses every tool at full strength. The choice depends on the question being asked, so match the tool to the question rather than drawing every diagram.

Computational, Design and Systems Thinking

🎯 (EC-12-08)

📌 Describe how computational, design and systems thinking skills are used in the design and development of an enterprise system

NESA names three thinking skills for design and development. They overlap, and students often blur them, so the safest way to describe them is to define each one, say what question it asks, and then show what it produces in a project. The definitions below are NESA’s (syllabus glossary), shortened.

Computational thinking in ClubHub

The rule “a court cannot be booked twice” looks simple until a computer has to check it. Computational thinking turns it into steps. Decomposition: split booking into finding the court, reading its existing bookings, comparing times and saving the booking. Pattern recognition: two bookings clash whenever one starts before the other ends and ends after the other starts. Abstraction: ignore who the member is and what the court looks like, and keep only court, start time and end time. Algorithm: for each existing booking on this court, if the new start is before its end and the new end is after its start, refuse; otherwise save. That algorithm can be drawn as a flowchart or decision tree and then tested with clashing and non-clashing times (see test data).

Design thinking in ClubHub

Design thinking starts with people. A common version of the process is: empathise (interview and observe members, the secretary and the canteen coordinator), define the problem in their terms, ideate possible solutions, prototype the best ones cheaply, and test with users, then repeat. It also weighs the effects of the design. ClubHub’s economic impact is the cost of hosting against the time saved; its environmental impact is less paper; its social impact includes members who are not comfortable online, which is why a phone booking option is kept. The Interactive Media notes describe the process in more detail in Design Thinking and UX.

Systems thinking in ClubHub

Systems thinking looks at the whole system and the connections between its parts. NESA’s glossary defines an enterprise system as “the combination of digital systems, people and processes that collect, manage and analyse data”, so a system is more than software. Adding online booking has consequences elsewhere: more games played means more canteen sales, which means stock runs out sooner, which means the reorder list matters more. That chain is a feedback loop between two parts of the system that were designed as separate modules. Systems thinking also asks who is affected outside the system (suppliers, members without internet access) and which data is shared between parts, so the Bookings and Stock tables must use the same court and member identifiers.

Collaborating and Managing Criteria

🎯 (EC-12-08, EC-12-09)

📌 Select key collaborating and managing criteria appropriate to the development of an enterprise project

• designing for ease of operation and maintenance
• clarifying each of the relevant informatics within the new system
• outlining the role of the participants, data and components used in the system
• negotiating user/client needs and wants
• working collaboratively

Criteria are the standards a project is judged against. To select them is to choose the ones that matter most for this project and to be able to say why. Choosing well means asking who will run the system, who will maintain it, what data it holds, what the client needs and how the team will work together. Those are the five criteria below. NESA asks you to select criteria “appropriate to the development of an enterprise project”, so a good answer names the criterion, says how it would be measured and links it to the scenario.

Designing for ease of operation and maintenance

Ease of operation is how easily the people who use the system every day can do their jobs with it. It comes from clear screens, sensible defaults, helpful error messages, few steps for common tasks, and accessibility: strong colour contrast, text that can be enlarged and controls big enough to touch (the W3C’s WCAG quick reference lists the standards). For ClubHub the canteen coordinator will use a tablet in a busy kitchen, so buttons are large and the stock list is sorted by the items that run out most often.

Ease of maintenance is how easily the system can be kept working and improved after the team has moved on. Design for it by building in separate modules, using meaningful names for tables, fields and screens, keeping a data dictionary and diagrams up to date, keeping settings (fees, court names, reorder levels) in data rather than in code, and writing maintenance documentation someone else can follow. Three kinds of maintenance are commonly distinguished (the terms are widely used in industry, though NESA does not name them): corrective (fixing faults), adaptive (changing the system because its environment changed, such as a new fee structure) and perfective (improving it, such as adding a reminder email). A system designed for maintenance makes all three cheaper.

Clarifying each of the relevant informatics within the new system

NESA’s glossary defines informatics as “the science of processing data for storage and retrieval”. To clarify the relevant informatics is to state, for every important piece of data in the new system, where it comes from, how it is processed, where it is stored and how it is retrieved and presented. If the team cannot describe this, it does not understand the system well enough to build it. The table is a small informatics map for ClubHub.

The map lines up with the data dictionary (see Data dictionary) and with the DFD flows: each data flow in the diagram should appear in the map. Because a booking holds a member’s personal information, the map also shows where privacy controls are needed; the Privacy and Security Principles notes explain the Australian Privacy Principles that apply when an organisation collects and stores it.

Outlining the role of the participants, data and components used in the system

A system is not only software. NESA’s enterprise system definition combines “digital systems, people and processes”, so an outline of the system lists the people (participants), the data they use and the components (hardware, software, networks and procedures) that connect them. Setting out roles also decides who may see or change which data, which is the principle of least privilege.

Negotiating user/client needs and wants

A need is something the system must do for the project to be worth building. A want is something people would like but can live without. Clients and users often express wants as if they were needs, and they sometimes want things that conflict. Negotiation is the process of working out, with the client and users, what will be in the system, what will wait and what will not be done. It ends with an agreement in writing, which in the ClubHub Gantt chart is the milestone “Requirements approved”.

A common way to sort requirements is a four-level priority list (widely used in industry, not a NESA term): must have, should have, could have and won’t have this time.

Negotiation in practice: listen and write down each request; ask why to find the need behind a want; show the cost in time and money; agree priorities together; record the decision and get it approved; and use a change request for anything new afterwards. Conflicts are solved by compromise. The secretary wanted to approve every booking; members wanted an instant confirmation. The agreed solution was automatic confirmation for financial members and secretary approval for guest bookings.

Working collaboratively

NESA’s glossary defines collaborate as “working with others towards a shared goal, through a variety of modes of communication. This may be achieved using a range of technologies, tools and processes.” Collaboration is a skill that has to be planned. Teams that collaborate well agree on roles (who leads, who decides, who tests), processes (how work is shared, reviewed and approved), communication (channels, meeting rhythm, how questions are raised) and records of what each person contributed, which is what the process diary is for.

Tools for Requirements and Limitations

🎯 (EC-12-08, EC-12-10)

📌 Apply tools to inform the requirements and limitations of an enterprise system

• interviews
• surveys
• analytical reports
• prototypes
• presentations of research results

Before a system is designed, the team needs to know what it must do (its requirements) and what will hold it back (its limitations). Requirements are the functions and qualities the users and client need, such as “a member can see which courts are free”. Limitations are the constraints on the solution: a budget of $800, a six-week schedule, a team of four students, members who prefer the phone, and privacy law. NESA’s Gantt chart example on page 12 of the Course Specifications is a requirements-gathering plan, and it is the order used here: interview participants, collate the results, document needs, identify processes and data, produce a data flow diagram, produce a requirements report, and reach a milestone.

Interviews

An interview is a planned conversation to learn how something works now and what people need from a new system. Prepare by deciding the purpose, choosing who to interview (the people who will use the system and the person who decides), writing questions, and asking permission to take notes or record. Use open questions that invite a description (“Walk me through…”) and follow-ups (“Can you show me?”, “Why is that?”). Listen more than you talk, avoid suggesting the answer, and read back what you understood. Collate the notes soon after so that detail is not lost; this is the “collate interview results” task in NESA’s example.

Surveys

A survey asks the same questions of many people so the answers can be counted. It is the tool to use when you need to know how many people want something. Write questions that can be answered quickly, use a mix of closed and open questions, and try the survey on two or three people first to find questions that confuse. Keep it short; long surveys lose people.

Analytical reports

An analytical report turns raw findings into conclusions. It usually has a purpose, a description of how the information was gathered, the findings (in tables and charts), an analysis that says what the findings mean, the limitations of the evidence and recommendations. For requirements, the most useful part is the link between each finding and a requirement or limitation. Below is an extract from ClubHub’s report. The survey figures are invented; 40 members responded.

A good report also states its limits: 40 responses from a membership of a few hundred are enough to show a trend but not to prove what all members think, and people who did not respond may differ. Finish with recommendations the client can act on. The charts in a report follow the same honesty rules as any data visualisation; see Data Visualisation.

Prototypes

NESA defines a prototype as “a trial product or model built to test an idea or process to inform further design development”, tested by users and systems analysts. Prototypes let the team find out whether the requirements were understood before anything expensive is built. A low-fidelity prototype is drawn on paper or as plain wireframes and is quick to change; a high-fidelity or clickable prototype looks and behaves more like the finished system and tests how it feels to use. The Interactive Media notes compare the fidelity levels.

ClubHub’s first prototype was three sheets of paper. Two members were asked to “book a court for Saturday at 10”, while a team member acted as the computer by swapping the paper screens. Both tried to choose the date before the court, which is why the storyboard was redrawn (see the iterations table in Managing and Documenting a Project). Record what users did, not just what they said, and be ready to be wrong.

Presentations of research results

A presentation of research results shares the findings with the client and team so that they can agree on the requirements and next steps. Plan it for the audience: the club committee wants to know the problem, what was found, what the options cost and what you recommend, not every survey response. A clear structure is: the problem, how we found out, what we found (three or four charts or tables), what we recommend (with cost and time), and the decision we need. Use one message per slide, label axes and units, do not truncate an axis to exaggerate a difference, and keep detail in the report. The presentation is also a control point: when the committee approves it, the “Requirements approved” milestone can be ticked.

Choosing a Development Approach

🎯 (EC-12-08, EC-12-09)

📌 Explore and apply the most suitable development approach to develop, modify and implement an enterprise system

• waterfall (structured)
• agile
• prototyping
• end-user
• outsourcing

A development approach is the way a team organises the work of building a system: in what order the stages happen, how much the client is involved and how changes are handled. There is no single best approach. To explore and apply them is to understand how each one works, compare them against a scenario’s needs and then use the one that fits, whether you are developing a new system, modifying an existing one or implementing it. NESA lists five: waterfall (structured), agile, prototyping, end-user and outsourcing.

The five approaches

Waterfall (structured). The stages (requirements, design, development, testing, installation, maintenance) run in order, and each is finished and signed off before the next begins. It relies on a complete specification at the start. Agile. The system is built in short cycles (often called sprints, of one to four weeks) that each produce a working increment; the client reviews it, and the next cycle is planned from the feedback. Prototyping. Early models are built and refined with users until the design is right, and then the final system is built (or the prototype is evolved into it). End-user development. The people who will use the system build it themselves, typically with spreadsheets, database packages or no-code tools, without a professional developer. Outsourcing. The work is contracted to an outside organisation that delivers the system, or part of it, to an agreed specification.

Two clarifications. Approaches are combined in practice. A large project might use waterfall for the requirements and contract, agile for the build and prototyping for the interface. Structured is NESA’s other name for waterfall: the steps are planned and followed in a fixed order.

Choosing an approach: an interactive chooser

Choosing an approach means weighing several factors at once. The chooser below scores each approach against six questions about a project. It is a thinking aid, not an oracle: the scores come from simple rules, and a real decision also depends on judgement. Try the ClubHub preset first, then change one answer at a time and watch which approaches rise and fall.

Applying the choice to ClubHub

ClubHub’s requirements are partly clear (the double-booking rule is firm, but the screens will change with feedback), the club committee is available every week, the team is small and skilled, the system is used by one organisation, and the club wants something usable soon. The scores point to agile with prototyping: two short sprints (bookings, then stock), each starting with a prototype tested by real users. Waterfall would suit if the club’s requirements were fixed and change was unlikely, but it would delay the first working booking screen until the end, when there is no time left to fix problems. Outsourcing would remove the team’s chance to learn the system and cost money the club has not got. End-user development, such as the secretary building a spreadsheet, would be cheaper but would not stop double bookings between two people using it at once and would depend on one person.

The same approaches apply to modifying an existing system. If ClubHub later adds online payment, a waterfall-style specification of the payment rules and security (money is at stake) could be paired with agile delivery of the screens.

Planning Implementation

🎯 (EC-12-08, EC-12-09, EC-12-10)

📌 Develop an implementation plan and test its feasibility for an enterprise computing system

• design thinking
• thinking and design tools, including storyboards, Gantt chart, decision tree
• risk analysis
• hardware and software integration
• training
• preferred system implementation method
• methodology for testing the system

An implementation plan sets out how a system will be put into use: what will be done, in what order, by whom, with what resources and risks, how people will be prepared, and how the team will know it works. Testing its feasibility means checking, before committing time and money, that the plan can actually succeed. Every part of the plan uses tools from earlier in these notes, so this section shows them working together, again with ClubHub.

Design thinking

NESA’s glossary describes design thinking as a process in which “a need or opportunity is identified and a design solution is developed”, with “the consideration of economic, environmental and social impacts” at its core, used “when trying to understand a problem, generate ideas and refine a design based on evaluation and testing”. In an implementation plan design thinking is the habit of asking how the plan will work for people, not just what the technical steps are. Testing the plan with the people who will live with it (the secretary, the canteen volunteers, a sample of members) finds problems while they are cheap to fix. The impacts should be written down.

Thinking and design tools, including storyboards, Gantt chart, decision tree

Three tools carry most of an implementation plan. A storyboard shows the screens in order so that the client and users can agree on the interface, and it is the plan for the build. NESA’s storyboard (Course Specifications p.9) has a title, a Help button, navigation buttons with the current page highlighted, a content panel and a dot-and-arrow for a button that opens another screen; see the Toolkit. A Gantt chart schedules the implementation tasks (installing hardware, importing data, training, testing, go-live) with owners and milestones; the ClubHub chart in Managing and Documenting a Project covers the build, and an implementation chart would extend it. A decision tree records rules, and, as shown later in this section, can also guide the choice of implementation method.

Risk analysis

Risk analysis identifies what could go wrong, judges how likely and how serious each problem would be, and decides what to do about it. The results go into a risk register. The steps are: (1) identify risks by asking the team, users and the client; (2) assess each by likelihood and impact (here Low = 1, Medium = 2, High = 3, multiplied to give a rating: 1–2 low, 3–4 medium, 6–9 high); (3) respond, by avoiding the risk, reducing it, transferring it (for example to a supplier or through insurance) or accepting it; and (4) monitor, with an owner for each risk and regular review. The Course Specifications do not prescribe a risk matrix, so a simple scale like this is acceptable if it is applied consistently. The Cybersecurity notes show the same idea for security risks.

Hardware and software integration

Integration is making the new hardware and software work together, and with what the organisation already has. It is a common source of late surprises, so the plan lists every component, what it connects to, and how each connection will be tested. Steps: (1) audit the existing equipment and data; (2) check compatibility (does the tablet’s browser support the screens? can the printer print the reorder list?); (3) plan data migration from old formats; (4) connect the components; (5) test the whole chain from a booking on a phone to a row in the database and a line in the report.

Training

Training prepares the people who will use and support the system so that they can do their jobs on the first day. Different groups need different things, and the best methods are matched to the group. Untrained users are one of the most common reasons a technically successful system fails, because they avoid it, make errors or ask the same questions again and again. Training should happen shortly before go-live, use the real system with practice data, and be evaluated afterwards by watching people complete tasks. The user guide written for training is also the operation documentation that is trialled in Part 4.

Preferred system implementation method

NESA’s Course Specifications (p.14) name four methods: direct, parallel, pilot and phased. The glossary describes system implementation as “the implementation method applied when introducing a new or redesigned enterprise system”. The Toolkit defines each one. The animation compares them for a generic four-office organisation.

ClubHub’s choice. A booking failure would not be dangerous, and it would cost some goodwill; and the system splits into two modules used by different people. The tree leads to phased: the stock module goes live first, used only by the canteen coordinator, and the booking module goes live three weeks later once the team has learned from the first. During the first fortnight of booking, the paper sheet stays available as a fallback, which borrows a short parallel run for the module that affects the most people. The reasons: a fault in the stock module affects one person, and by the time booking goes live the team has a working, tested system and a trained secretary. The trade-off is that the club runs two ways of working for a while and full benefits arrive later than with direct implementation. Rejected: direct implementation, because a booking fault would reach every member on the first day; and full parallel running, because the secretary would enter every booking twice.

Methodology for testing the system

A testing methodology is the plan for how the system will be tested: which methods, in what order, on what data, by whom and to what standard. NESA (Course Specifications p.15) names six methods: functional testing, acceptance testing, live data, simulated data, beta testing and volume testing; the Toolkit defines them. A methodology puts them in a sensible order and says when testing is complete, using pass criteria agreed before testing starts.

Testing the plan’s feasibility

The last step in developing an implementation plan is to test whether it is feasible. A feasibility test asks a set of questions before the team commits. The following five questions are commonly used in industry (NESA does not name them, but the syllabus does ask you to test feasibility). A plan that fails one may be changed, delayed or dropped, and it is better to find that out on paper.

Verifying and Validating a System

🎯 (EC-12-09, EC-12-10)

📌 Verify and validate an enterprise computing system

• evaluating test data
• trialling the operation and maintenance documentation
• reviewing the impact of system implementation within relevant environments
• modifying designs to improve functionality
• testing, evaluating and maintaining the developed enterprise computing system

“Verify” and “validate” are often used as if they meant the same thing, and in this dot point they do not. A team that only verifies can build exactly what the specification says and still fail, because the specification was wrong. A team that only validates can please the users in a demonstration and still ship a system full of faults. Both are needed.

Notice that the words are also used for data. To validate data is to check that it is reasonable and allowed before it is accepted (a range, type, presence or format check). To verify data is to check that it was entered or copied correctly, for example by entering it twice or comparing it with the source. The Data Visualisation notes use these meanings. NESA’s dot point asks you to verify and validate an enterprise computing system, so a system-level answer is usually wanted, but read each question’s context and use data-level examples where the question is about data entry.

Evaluating test data

A test is only as good as its data. Evaluating test data means two things: judging whether the set of test data is good enough to give confidence (it is the right data), and then judging what the results say about the system. Good test data covers three kinds of values. Normal data is typical, valid data the system should accept. Boundary data is on and next to each limit: for a rule of 30 to 120 minutes, test 30 and 29, and 120 and 121. Erroneous data is data the system must reject: the wrong type, a negative number or a blank. The expected result for every test is worked out before testing, from the requirements, so you are checking the system rather than believing it. The Toolkit shows the same method on a delivery flowchart. The table tests ClubHub’s rule that a booking must last from 30 to 120 minutes.

Evaluating the results. Two tests failed. Test 5 shows the length check uses “less than 122” instead of “not more than 120”, a classic boundary error that only a boundary test would find. Test 7 shows the screen assumes the input is a number. Each fault was logged, the fix made, and both tests retested together with tests 3 and 4, because a change to one check can break a neighbouring one (this is called regression testing); they then passed. Evaluating the test data itself: the set covers all three data types and each path through the booking decision tree, and every test has an expected result. What it misses is also worth writing down: two members pressing Confirm at the same instant, times that cross midnight and very large volumes of bookings. Those gaps are why the plan adds volume and beta testing.

Trialling the operation and maintenance documentation

Documentation is part of the system: it is how people run it and keep it running. Operation documentation (often a user guide) explains how to do each task, what the messages mean and who to contact. Maintenance documentation is written for the people who look after the system: how it is built (diagrams, data dictionary, schema), how it is configured, how backups are taken and restored, how to apply updates and a log of changes. A guide is only good if a person can follow it, so it has to be trialled: give it to someone who was not involved in building the system, ask them to complete real tasks using only the documents, watch without helping, and note where they hesitate, get stuck or make mistakes. Then fix the documents and trial again.

A trial is also validation: it tests whether the documents meet the real needs of the volunteers who will use them. The trial results go in the process diary, and the changes are versioned so that the guide always matches the system.

Reviewing the impact of system implementation within relevant environments

The syllabus asks for a review of the impact of the system on the environments it operates in. NESA’s outcomes refer to the effects of enterprise systems on the individual, society and the environment, so a helpful way to organise the review is to ask about the people and organisation using it, the wider community, the technical environment, the natural environment and the economic environment (this list is our reading of “relevant environments”, not a NESA list). Compare the situation after implementation with the baseline you recorded before, using the success criteria and evidence such as survey responses, logs, costs and feedback. Look for unintended effects as well as intended ones.

Modifying designs to improve functionality

Testing and impact reviews produce evidence that the design can be better. Modifying a design is a controlled process, not a quick fix: identify the cause, decide the change against the success criteria, update the design documents first (storyboard, data flow diagram, decision tree, data dictionary), make the change, retest the change and the features around it, and record it in the process diary and a change log. Changing the documents first keeps the team from ending up with a system nobody can describe. This is the iterative approach from Part 1, applied after release.

Testing, evaluating and maintaining the developed enterprise computing system

The last activity brings the parts together. The team tests the whole system with the methods in its plan, evaluates it against the criteria set in the problem definition, and hands over a system that can be maintained. NESA’s glossary describes evaluating as making “a judgement based on criteria”, so a good evaluation is a judgement with reasons, not a list of features. The table evaluates ClubHub against its four success criteria.

Model evaluation. ClubHub meets its main purpose: the club no longer double-books courts, and the coordinator gets a reorder list with one action. It was delivered on time and within budget, and the trial of the documents found problems that would have frustrated volunteers. The main weakness is security: role restrictions were tested by the team, but no independent review has been done, and member data makes that a priority. On balance the project is a success, and the recommended next steps are a security review, reminders (should-have) and a review of fees handling before online payment is considered.

Maintaining the system. Once it is live, the system needs care. Plan who does it, how often and how the work is recorded. Commonly three types of maintenance are distinguished (the terms are widely used, not NESA’s): corrective (fix faults, such as the length check), adaptive (respond to change, such as new court names or fees) and perfective (improve, such as the reminders).