Exercise Notes
- All stages of the software development life-cycle (what each stage contains, including the inputs and outputs)
- Roles and responsibilities within the software development lifecycle (who is responsible for what)
- The roles and responsibilities of the project life-cycle within your organisation, and your role
- The similarities and differences between different software development methodologies, such as agile and waterfall
- Organisational policies and procedures relating to the tasks being undertaken, and when to follow them. for example the storage and treatment of gdpr sensitive data.
- Follow company, team or client approaches to continuous integration, version and source control
Pizza app
The Software Development Lifecycle is intrinsically linked with teamwork, responsibilities and the following of defined processes. As such, this module exercise will involve working as part of a team to step through the lifecycle of a new pizza delivery app.
It’s fine to split up the work among you (though note that some sections will rely on other sections being complete) but try to at least work in pairs, and make sure everyone in the group knows what’s happened at each stage if questioned!
For sections with deliverables, the deliverables will be highlighted in bold.
Feasibility study
Before we spend money developing software, we should conduct a Feasibility Study. This is a cheap way to determine how likely a project is to succeed. The output required from your Feasibility Study is a Business Case. This could be in the format of a powerpoint, and should include slides on:
- Domain analysis:
- What do you know about the (fictional) pizza delivery app business? You can be creative with this. For example, “Pizza Co. is a high-end, artisanal pizza company based in Soho in London.”
- What is specific to this company that isn’t immediately obvious? e.g. “Pizza Co. caters to a typically eco-conscious consumer so the app needs to demonstrate how carbon-efficient the delivery options are”, or “Pizza Co. is hugely over-subscribed on weekday evenings as it caters to office-workers who work long hours”.
- Technical feasibility:
- What are the main technical risks of the project? What might be impossible or difficult?
- How are you going to reduce each risk? Research? Perhaps by making a prototype?
- Cost/benefit analysis:
- How much money will the app make vs. the cost? Include direct costs (e.g. consulting fees) and indirect costs (e.g. training expenses)
- What benefits will it bring to the company? e.g. productivity, cost-savings, time-savings and profitability. Benefits can be intangible as well as monetary. Often it’s easier to estimate these as percentage increases rather than absolute.
- How long will it take to break even? Could you include both optimistic and pessimistic projections?
- Risk report – collate all the risks you’ve examined into a table. Each risk should include likelihood (and the conditions to trigger it), impact, severity and mitigation columns.
Present your outputted Business Case to the rest of the group. Make sure to:
- Explain the business at a high level
- Explain the concept for the app
- Discuss the pros and cons that you’ve identified
- Give a recommendation for why you think it’s a good/bad idea to build the app.
Requirements analysis
We’ll be working from here onwards on the basis that our idea is feasibile. The next stage is to find out – in detail – what the customer wants. The output of this analysis should be a Requirements Specification.
Requirements gathering
In pairs, take turns to be the Business Analyst and the Customer.
- What do you care about?
- What do you like/dislike about the current process (where there is no pizza delivery app)?
- What would make your life easier/make your shop more profitable?
- Which requirements are most important to you?
- Ask the Customer insightful questions
- Be sure to note down their answers!
Requirements prioritisation
Next you should take your list of Requirements and prioritise them. Customers will (almost) always have more requirements than can be built for their budget! Your job is to help them work out:
- Which requirement is the most important to achieving their business goals?
- What is the minimum we could build to enable them to launch a product? – this is the Minimum Viable Product (MVP)
The output of Requirements Prioritisation should be a Scope for the project, i.e. a list of features to be build in version 1.
Presenting your findings
Lastly we can take the Scope and write out the requirements in more detail. As you do this be sure to consider what will the developers and designers need to know in order to deliver what the customer is expecting? Be careful to specify the requirement and not a proposed solution for meeting that requirement.
At the end of all this you should have a Requirements Specification (as a Powerpoint, or otherwise) that contains:
- Requirements Gathering summary
- Requirements Prioritisation (including what’s included in the MVP)
- Requirements Specification i.e. details on the in-scope requirements
Design
You’ll need to have completed the “Requirements prioritisation” section before starting this part of the exercise.
By the end of the Design process you should have an output of a Design Specification, containing: Block Frames; Wire Frames; a System Architecture Diagram; and a Code Specification.
User interface
-
The first step of designing the user interface is to come up with User Personas. There should be more detail on this in your reading but in brief you should produce 3-4 personas, each describing:
- How comfortable are they with technology?
- What are they worried about?
- How will they be using the app? e.g. desktop, tablet, phone
-
Next you should document some User Journeys. These should describe your Users’ (from User Personas!) experiences with the system. We particularly care about the sequence of events the user takes on their journey, more than what the app looks like/what pages the events occur on.
-
Prototypes based on the User Journeys are a great way to get a better understanding of what the app will look like. Today we’ll create Paper Prototypes (prototypes drawn on paper) rather than creating high-fidelity Mockups using Photoshop – that would take too long. Create the following Sketches:
- Block Frames – a low-fidelity look at what pages your app has and what sections are on each page
- Wire Frames – higher fidelity that Block Frames, these should show individual buttons, navigation items and icons
System architecture
Next you’ll need to design your System Architecture Diagram. This should show:
- What components there are
- How the components interact
- Which users interact with which parts of the system
Here “component” refers to parts of the system. A non-exhaustive list might include a mobile app, a website, a server or a database.
Low-level code specifications
Use your architecture diagram to come up with a Code Specification. This is a low-level, detailed description of how a feature will be implemented. Choose one small feature of your app and write a Code Specification for it. Be sure to include:
- What should be shown on screen?
- What ways might the user action fail (e.g. if they lose internet connection, or if the shop is closed)? What should we do in each case?
Development
Agile vs. waterfall
Choosing a development methodology to follow may depend on the nature of the project in hand, but also personal (and company) preference. Some projects require an iterative process and others require a sequential approach.
Consider the agile and waterfall methodologies from your reading. Discuss as a team which of these methodologies is best suited to the development of your pizza app.
Try to come up with pros and cons for each rather than jumping to a conclusion without evidence.
Team structure
Given the methodology you’ve chosen to follow, can you outline what your development team might look like? Produce a table with a column for Role and a column for Responsibility. e.g. Role – Developer, Responsibility – deliver work throughout the sprint.
Testing
Unit tests
Come up with a list of (at least 3) unit tests for the pizza app. Remember, unit tests should test a small, self-contained component of the app!
Integration tests
You’ll want to have completed the “System architecture” section before starting this part of the exercise.
Consider the components that you defined in your System Architecture diagram. What integrations are there between these components?
Based on this, come up with a list of (at least 3) integration tests we could have to tests this interactions between components.
System tests
When we’re testing pizza app, what tests would work well as end-to-end (system) tests?
If you’re unsure of the difference between system and acceptance tests, take a look back at the reading. System tests are usually performed by developers and can look for edge-cases (amongst many other things!) Acceptance tests are performed by product owners and look to ensure user requirements have been met.
Acceptance tests
You’ll need to have completed the “Requirements gathering” and “User interface” sections before starting this part of the exercise. In particular you should have a list of user journeys to hand, as well as a Requirements Specification.
Look through your Requirements Specification and consider your user journeys. Convert as many requirements into Acceptance Tests as you can. Details the steps of each test you define. What output do you expect at each stage? If relevant, which of these tests will be manual and which could be automated?
Organisational policies and procedures
Now that we’ve stepped through the software development lifecycle for a fictional app, it would be great to know more about these methodologies in practice. Take time before the half-day workshop to chat to colleagues in your organisation who fulfil some of the roles discussed today. Ask them if your company has any specific policies or procedures related to their role.