SDLC

SDLC - Create

• Most labour-intensive stage
• Programmers write the code
• UI designers create the interface
• (Unit) Testing – Very important at this stage
• Users may be involved as 'Consultants!'
• May involve re-design and re-writing – Iteration
• Patience required!
• Flexibility required!

SDLC – Evaluate

• Testing essential to ensure
• Functionality
• Correctness
• Consistency
• Unit testing should be done at the Coding stage
• More testing remains to be done...
• Functionality testing
• System testing

• Acceptance testing

• Test Data:

• Conditions/Inputs that produce a known result
• Used to test every part of the software
• Must be prepared in advance and independently
• Testing can be manual or automatic
• Should include
• Normal values
• Incorrect values
• Extreme values

• Boundary values

• Functional Testing

• Compliance with specification – fit for purpose
• Usability
  • User friendly?
  • Intuitive
  • Easy to find ones way around the syste?
  • Accessibility – easy to access functions of systems?
  • Feedback – appropriate and useful error messages
  • Recovery from errors – does it crash?
  • Security? Too easy to access system?
• Identify Functions or Features of the system
• Then for each one:
  • Create test data
  • Determine expected output
  • Carry out test(s)
  • Compare actual with expected results
• System testing
• Looks at complete system rather than Functions
• Ensures conformance with agreed specification
• Alpha testing
  • In-house
  • Satisfies technical team that the system works
• Beta testing
  • On-site
  • Gives assurance to the client that system is fit for purpose
• Alpha testing
• In-house
• First line of defence!
• Test as many paths through the system as possible
• Find bugs before the users discover them!
• Beta testing
• On-site
• Early (Beta) version of system released to users.
• Users test the system in 'real-life' environment
• Record errors and notify development team
• Wider range of use-cases and scenarios can be tested
• Continues until all (identified!) issues have been resolved
• When all issues have been resolved, the user will be asked to Sign-off
• Aka. Acceptance testing
• Evaluation stage
• After Alpha and Beta testing has been completed
• Product has probably been signed-off and in use
• Has been deemed 'Acceptable' but not perfect!
• Often a trade-off of Features vs Time available
• Modifications may be required
• Unforeseen 'features' may have been deferred to avoid Scope-Creep
• Might be time to plan Version 2
• Evaluation Stage – Questions to be Asked
• What about the Product?
• Does the system do what was required?
• How well does it meet requirements... in terms of:
  • Introduction to workplace?
  • User Ownership?
  • Response time?
  • Coping with data volumes?
  • Reliability?
  • Usability?
• What about the Project?
  • How about Cost vs Budget?
  • What about Value for Money?
  • How did we score on the timescale?
  • How easy to maintain and enhance the systems?
  • How long will it last?
  • What have we learned from the project?

SDLC – Document

• Effective Communication is KEY
• Informal Communication:
• Meetings, Phone calls, email, etc.
• Formal Communications:
• Project documentation, Feasibility study, Project plan, etc.
• Informal Communications:
• Meetings – Minutes should be recorded and made available as required
  • Decisions made
  • Actions agreed
  • Issues to be resolved
• Phone Calls
  • Any important or relevant phone calls should be logged in a diary or similar
• Correspondence
  • Letters
  • Emails and other messaging
• Changes to Requirements, Plan or Design should be documented
• Project Documentation
• Feasibility study
• Requirements specification
• Design documents
• Project plan
• Source code – including Libraries, etc.
• NOTE: Code should include Comments and other technical support
• Test plans and Test data
• Test results and details
• System Documentation
• Installation and Setup guides
• Training and End-user Documentation

• Evaluation report

• Reporting

• Inform stakeholders of progress
• Regularly!
• Manage expectations

• Maintains Trust and Confidence

• Reporting

• Avoid technical language (jargon) where possible
• Identify and report potential problems ASAP
• Timely information helps timely intervention
• Reduces risk of Cost and Time overruns

Software Project

• Usually, a Need or Problem is identified
• Urgent response needed
• Competitive factors
• Changing marketplace
• Changes in legislation
• Need to control costs
• Improve lead / response time
• GDPR
• etc..
• The main players:
• Business Analyst
• Project manager
• Systems Analyst
• Designer
• Developer
• Tester
• User liaison and training
• Administrative support