Unit 1 SDLC
Unit 1 SDLC
This unit considers the equivalent of the old MYP Design cycle.
At university level for a Computer Science course, the design
cycle is known as the SDLC: System development life cycle
(some books substitute "system" with "software").
* Requirements analysis
* Design
* Implementation
* Testing
* Evolution
● Project scoping
● Stakeholder consultation
● Project research
● Requirements planning
It is inevitable that a project scope will change over time. When that occurs, beware the challenges of scope
creep vs scope discovery:
● Changes to the scope that make it more clear / less vague = Scope discovery
● Changes that make the scope less clear / more vague = Scope creep
1.2 Stakeholder consultation
Who is relevant? Employers, employees, customers…?
Who will use the system?
Who will depend on the system (even if they don’t use it directly)?
Who will provide information the system depends on? (even if they don’t enter it directly)
Who is paying for the system? (why?)
Possible strategies for obtaining requirements from stakeholders
Surveys
Interviews
Direct observations
Document collection
Failure to involve all relevant stakeholders may lead to software that is not suitable for its intended use! (The
manager doesn’t necessarily always know what the clerical staff do!)
Effective collaboration and communication between all parties: client, developer, end users.
Consultation should occur continually throughout the lifecycle to identify problems early.
Be aware of privacy issues – being able to get honest, frank information from a stakeholder without fear of
retribution (eg: a staff member who might have valuable insight into how some part of the system doesn’t
work the way management thinks it does) – create an environment where you can extract those valuable
nuggets
Exercise
Split off into pairs - one taking the role of customer, one taking the role of developer. The customer comes up
with an app/software project they want the developer to “design”. The developer must ask questions to
ascertain:
● A scope document: Explicitly list “in scope” and “out of scope” items
● Identify stakeholders
● Requirement specification: Functional and non-functional items
Reverse roles when ready. Save these project outlines as we will use them later.
1.3 Project research
● Examine the c urrent system that yours will replace – strengths, weaknesses, idiosyncrasies.
● Examine c
ompeting products – strengths, weaknesses, idiosyncrasies.
● Examine y our capabilities – what are you capable of producing? If you need additional expertise,
what can you afford to recruit?
● Examine the l iterature (journals, online forums) – how are other people addressing the problem?
When researching your project, don't forget to account for international factors.
● Does your program only have to work for a homogeneous group of people in the same location? Or
might you have to deal with different time zones, different languages, different conventions in date
formats? Things can get very complex very quickly as these videos demonstrate.
● The Problem with Time & Timezones - Computerphile
https://www.youtube.com/watch?v=-5wpm-gesOY
● Internationalis(z)ing Code - Computerphile
https://www.youtube.com/watch?v=0j74jcxSunY
1.4 Requirements planning
Turn your project scope into a detailed set of requirements that you can give to your engineering team. Your
requirements are generally split into functional and non-functional requirements.
Non-functional: Doesn't affect what the program will actually do, but will impact on creating it anyway. For
example:
● The system shall run on Android / iOS / the web.
● The system shall be compatible with Microsoft SQL / Google Firebase
● The system shall share data with (insert other existing product here)
● The system shall be operational in 3 months
● The system shall store its data within Switzerland (due to privacy laws)
● The system needs to be produced within $X budget
2. Design
The aim of the Design phase: Create a plan on paper before hacking away at code
There are a range of diagrams that may be useful when designing a new software project. We will learn a few
key ones now...
Gantt charts
A gantt chart is a type of bar chart that illustrates the timeline of a project schedule. Each task is assigned a
row, and the horizontal axis is time scale.
Within the Gantt chart it is important to identify tasks that are prerequisites for other tasks so as to find the
critical path and other potential bottlenecks.
DFD context diagram – shows the “context” (environment?) your system is part of, particularly external
entities it has a relationship with
DFD level 0 diagram – shows inside the main / top level process of the system: the core functional parts and
the flow of data between them.
1
Examples from h
ttp://editorialzone.blogspot.com/2010/09/data-flow-diagrams-of-online-shopping.html
Data Flow diagrams: Level 0 diagrams
Level 0
Party finder example
Exercise
Pick one of the options the class came up with earlier, and create a context and level 0 DFD for it.
System flow diagrams
Purpose of the diagram: To capture the flow of documents through a system and to show who is responsible
for performing the different activities within the system.
This includes physical processes that may occur outside any particular piece of software. It provides a
“system” view rather than an application view. Manual as well as computer processes are represented.
Whereas the logical flow diagram can be used to design the decision making logic of an algorithm, the
system flowchart might be used when observing and documenting how users interact with an existing
system.
Nomenclature note: Researching for this diagram online: Searching for “system flowchart” comes up with
very little. Searching for a process flowchart produces more helpful resources.
Symbols:
● Document - To reprepresent documents being passed around the system. Can be used to denote
electronic but typically used to denote paper documents (a printed receipt or a voucher would
examples).
● The arrow creates a dependency. One can’t start until the other has ended.
● Data storage paper file - Think a paper file or filing cabinet
● Data storage disk - An electronic file on the computer
● Computer process - As it sounds. When deciding if you have to create a process bubble, keep to the
general rule that a computer will always require a process to store or receive information.
Entities
Some versions of this diagram create columns for the individual entities. Whatever entities you have
identified in your DFD should be listed. The IB mark schemes have not required this. My examples below
include it anyway.
Example 1 - Consider “customer at a cafe”....
● A customer uses a phone app to order movie tickets online. The cinema online server receives the
order and stores in a database and sends back a ticket QR code for display on the phone screen.
● On arrival at the cinema, customer shows the QR ticket code to a computer
● The system checks if the order is valid, and then prints a cinema ticket, otherwise it gives the
customer an error screen.
● The customer shows the printed cinema ticket to the door person to gain entry.
Question 1 - Student submits work to teacher for marking….
● A student creates a Google Doc containing an assessment
● Student uploads assessment to Google Classroom. Google Classroom stores that assessment and
notifies the teacher it is there.
● Teacher reviews work and enters a grade. Google Classroom stores that grade and notifies the
student their work has been graded.
● Student views grade.
Further resources
● System Documentation - Part VI: Creating the Flowchart ( 24:53)
https://www.youtube.com/watch?v=YTcah66oYJU
● System Flowchart Symbols (5:25) by Sharon Walkey
https://www.youtube.com/watch?v=AaiQehBm2Y4
● System flow charts (8:31) by Comp Franklin
https://www.youtube.com/watch?v=QF-ml1QVQYs
● Basic FLOWCHARTING for auditors - documenting SYSTEMS OF INTERNAL CONTROL (15:02)
https://www.youtube.com/watch?v=2De4hO3lu14
Structure charts
Provides a top-down approach to explain how the different parts of the program are put together.
Simplistically:
● Wireframe: outlines the arrangement of textual and media elements. Wireframing tools allow both
parties—the designers and the client—discuss and comment on a sketch.
Some possibilities:
You had the signed and agreed scope, now have them agree to the design you've built as the proposed
incarnation of that project before you start serious development!
3. Implementation
The aim of the implementation phase: Build it compliant to the design
A lot of major products are moving to a SaaS model (eg: Microsoft Office 365, Evernote, Adobe Suite).
Sometimes you aren't even installing anything on your computer because you are using the "software"
through their web portal. Eg: Google Docs.
Modern tools available give wider options for how your new technology might be implemented. Specifically a
huge development that is comparatively recent is the emergence of cloud computing.
Amazon Web Services, Google Cloud, and Microsoft Azure are the three big global players in this space at the
moment, though there are others.
What technologies will you use to build your project and why?
Common concerns/questions about using the cloud reside around you lacking ultimate control over where
your data resides, who has access to it. Trust in the cloud provider is necessary for this approach to work.
The lesson of Google Chrome in relation to auto-updates done “right”. There are a multitude of reasons why
Google Chrome burst onto the browser market to rapidly dominate market share. See Full Circle Design if you
are interested in some well articulated reasons. The aspect that is of relevance here is automatic updates. No
longer does the user have to be prompted (nagged) to download updates, go through an install screen,
possibly reboot their computer etc; Google Chrome keeps itself up to date for you behind the scenes. This
meant new features, bug fixes, security patches, are all rolled out automatically.
3.4 Implementation issues
What implementation / conversion method will you use?
● Parallel running - new system runs simultaneously with the old for a given period of time
● Phased conversion - new system is implemented one stage at a time
● Pilot running - new system is tried out at a test site before launching it company-wide
● Direct change over - entire system is replaced in an instant
Parallel running
The new system is started, but the old system is kept running in parallel (side-by-side) for a while. All of the
data that is input into the old system, is also input into the new one.
Eventually, the old system will be stopped, but only when the new system has been proven to work.
Advantages...
● If anything goes wrong with the new system, the old system will act as a back-up.
● The outputs from the old and new systems can be compared to check that the new system is running
correctly
Disadvantages...
● Entering data into two systems, and running two systems together, takes a lot of extra time and effort
Phased conversion
The new system is introduced in phases (stages, or steps), gradually replacing parts of the old system until
eventually, the new system has taken over.
Advantages...
● Allows users to gradually get used to the new system
● Staff training can be done in stages
Disadvantages...
● If a part of the new system fails, there is no back-up system, so data can be lost
Pilot running
Advantages...
● All features of the new system can be fully trialled
● If something goes wrong with the new system, only a small part of the organisation is affected
● The staff who were part of the pilot scheme can help train other staff.
Disadvantages...
● For the office / department doing the pilot, there is no back-up system if things go wrong
Direct changeover
The old system is stopped completely, and the new system is started. All of the data that used to be input
into the old system, now goes into the new one.
Advantages...
● Takes the minimal time and effort
● The new system is up and running immediately
Disadvantages...
● If the new system fails, there is no back-up system, so data can be lost
Case study
https://erichmusick.com/writings/technology/1992-london-ambulance-cad-failure.html
4. Testing
Elements to be considered within the testing phase:
User documentation
The quality of your user documentation will affect the rate of implementation, or even overall success, of the
new system.
What to provide?
● Big fat textbook style “user manuals”? … pretty old school. Some people don’t like reading off a screen.
Updating the textbook with changes will be difficult though.
● Help files
● Online support (online chat to support, online community forums)
● Videos
What is best for YOUR users in YOUR project? No one-size-fits-all approach. Along with the documents, there
might be a need for actual “training” too…
● Self instruction
● Formal classes
● Online course
● 1:1 coaching
Backups
Data can be lost through a variety of ways. How will your system protect from:
Eg: hotels/airlines losing all record of reservations? Banks losing record of all account balances? loss of
medical records?!
A data loss prevention regime should include a mix of: failover systems, redundancy, removable media,
offsite/online storage
Strategies:
● Hot spares
● Cold spares
● Backups
● At least 3 copies
● At least 2 different forms
● At least 1 copy offsite
Gather stakeholder feedback on the whole experience (design, migration, training) not just the functionality of
the final product.
Start the cycle all over again with your identified changes!
Past paper questions for review
(refer to separate document)