Embed Size (px)
Citation preview
2
Course aim
• “To provide experience in the development of larger scale software, as an introduction to software engineering”
• To allow you to demonstrate your ability– To design a system relative to a given specification
– Related to programming techniques and systems analysis and design
– To effectively code the design– Related to programming foundations and programming
techniques
– To test the code in an appropriate manner– To document the system
– A technical description of the software
– To manage all of the above
3
How• I will provide initial specifications for 5 systems
– e.g. machine translation, search engine– You choose one
• Cover these in next lecture• Develop a specification of your system• Develop a plan for the design, implementation, etc• Build a system to meet your specification• Test the system
– Covered in testing lecture
• Document the system in a formal report– Covered in writing lecture
• Note: this is an individual exercise!
4
Prerequisites
• Already you know– How to design– How to program (in Java at least)
• Later classes will give experience in – Software correctness
• Formal approaches to proving code is correct
– Software quality• Techniques for designing and implementing quality
software
• This class is the opportunity to show what you have learnt already in a practical setting
5
Course details - lectures
• 6 lectures • Lecture 1 :Introduction (this one)• Lecture 2 :Practical exercises• Lecture 3: Testing • Lecture 4: Writing• Lecture 5: Practical exercises revisited• Lecture 6: Open session
• Intended to support practical work• All lectures will be on Tuesdays (K317)• Lecture notes and lecture dates at
http://www.cis.strath.ac.uk/~ng
6
Course details practical work
• NO EXAM!• 4 practical exercises
• Revision practical– Finish off work from last semester especially stuff on binary
trees and binary search trees
• Initial practical (10%)– Warm-up– Week 6
• Assessed practical (90%)– Week 1
• Details of practicals and dates in next lecture• Labs start next week 2
7
Books
• No required text!• Pressman R; Software Engineering: a practitioner’s
approach, fifth edition, European adaptation, McGraw-Hill, 2000.
• Van Vliet H; Software Engineering: Principles and Practice, Wiley, 2000.
• Fenton N E, Pfleeger S L; Software Metrics: a rigorous and practical approach, Thomson Computer Press, 1996.
• Schach, S. Object-oriented and classical software engineering (using Java and UML). 5th edition. McGraw-Hill
• Sommerville, I. Software engineering. 6th Edition. Addison-Wesley
• But probably want to invest in a Java book
8
Introduction
• This course is about software engineering• How we build a software product and the
process by which we build it– requirements & specification– design– implementation– testing and evaluation– maintenance– retirement
• These steps are known as the software lifecycle
9
Requirements/specification
• In this stage we decide– What tasks the system will perform– I will give minimal specification– e.g. Spell-checker
• input: English dictionary• output : an list of those words in the input text which are
not found in the dictionary
– Also some hints and restrictions• Must use bst to store words in dictionary• Should allow user to add news words
10
Requirements/specification
• You decide what else (if anything the system is to do)– E.g. does it have a gui?– how does it handle punctuation? – do users type in input text or does it come from a
file?
• What assumptions are you making about system?– This is your system– Minimal/better solutions
11
Requirements/specification
• (Usually) we also consider language to be used– Hardware – Problem
• Choose a language we know well?– Low cost, may choose wrong language
• Choose the right language, but increase costs?
– Experience of team • (your experience, demonstrator’s experience)
12
Specification decisions
• Set criteria for end system
• e.g.• Correctness – how well does it fulfil its
function?• Efficiency – how well does it operate?
• High correctness and efficiency cost money and take longer to build
• Effort and cost must be appropriate to problem
13
Some criteria for correctness
• Correct? – usually works?
• e.g. telephones, cars, my pc• This may be acceptable, e.g. if works often enough• Spell-checker will detect most incorrectly words?
– passes all tests attempted? • Need to define tests• Spell-checker will work under the conditions I specify?
– guaranteed to work in all cases• Best but is it appropriate?• Spell-checker will give some sensible response for any
user input?
14
Criteria for efficiency
• Efficient? – usually runs in acceptable time?
• When does it not, are these cases likely/appropriate?• Spell-checker - will give response in 10ms for
dictionaries of less than 1000 words?
– always runs in acceptable time? • What do you mean by acceptable?• Spell-checker – will operate in O(n) time?
– runs in optimal time? • Investigate all possible barriers to efficiency and prove
your system runs as fast as possible• Again, best but is it necessary?
15
Criteria
• Also can consider scale– One-off calculation requires less rigorous
methods than code to be re-used
• And consequences– Can your mistakes kill people?
• In this course you make these decisions– Must be sensible…– Must be justified…– Must be planned…
16
Planning
• Before you start develop a plan • Biggest danger in any software project
is underestimating time • Things to think about
– What are your skills/weaknesses?– What are the milestones?– What checking and adjustments are you
going to do?– What are the dependencies?
17
Gantt charts0 1 2 3 4 5 6 7 8 9 10
T1
T2.1
T2.2
Duration of activity
*
Milestone
In this project5% marks come from development of initial plan
18
Design
• Once we have specification of functions– Move to system design
• Do not need formal techniques such as UML– For this class (well-explained) English description
is sufficient
• You are strongly advised to make (and keep up-to-date!) a formal record of all design and implementation decisions – no matter how trivial!
19
Design
• Especially for user interaction, use techniques of defensive programming – each method should error-check its input first– Spell-checker?
• Don’t assume legitimate input, i.e. whole words• Check punctuation in middle of words ‘ca?t’• Assume users will read instructions
– Enter word to be spell-checked then click ‘go’
– Users will click button before entering text
– Users will always do unusual things
20
Defensive programming
• This is also important because – other programmers won't ever have known,
or will make invalid assumptions about what code can do
• So make it obvious (from code) what input is correct
– our program should always react gracefully • no matter what peculiarities may be fed to it!
– you will forget things as your code evolves/changes
21
Defensive programming• Defensive Programming has in essence two
parts – Checking all input (each entry at a time)
• Take input a character at a time• If correct cast input to appropriate form. • -e.g. use successive characters 1,2,3 to input integer 123?
– Check each character is in range ‘0’..’9’ – If all correct put whole character series together and convert
to integer– Checks for duff data 12x abc 0a1 etc
– if no sensible input available give suitable error message and then jump to a legal exit from program
22
Maintenance costs• Also, remember maintenance costs • Maintenance – changing it
– To do something new, to do something better, to do fulfil the original requirements
• Make the code easier to change• sound modular design eases reading as well as writing • so do "small" things like careful ... • choice of identifiers
– single letters seldom good!
• layout– unless house style required, anything consistent and
justifiable (with spaces between but not within blocks of code)
• comments
23
Rest of lifecyle• Testing
– What tests do you apply to individual modules?• How do you know if your code is correct
– (answer: never)– Bu the more different tests you apply the more confident you
can be– Testing is about finding errors
– How do you know if system meets requirements• Different types of requirements
– Usability – Functional– Non-functional
– 25% of marks come from ability to test your own system
24
Documentation
• Documentation– Who needs to know about your system
• Me• can they understand it• can they change it• can they use it
– 30% of marks will come from report
25
Management review
• 5% of marks come from developing an initial plan for the project
• Another 5% comes from your assessment of– How realistic your plan was– How well you stuck to it
• This is not a trick– Aim is to demonstrate learning not
perfection
26
This course• Testing lecture
• how testing is to be handled
• Writing lecture • how to write a technical description of your software
• Note: you are not going to be assessed on– Your ability to build the most complicated system
• A simpler system built well is better than a half-finished masterpiece
– Your ability to write a breathtaking epic of a report• Simple, concise English is fine
– Your ability to do it all in one night
27
Next time• We will go over the assessed work
– Sneak preview at http://www.cis.strath.ac.uk/~ng
• Use programming techniques newsgroup for discussion
• strath.cis.teaching.ug.programming-techniques
• All pieces of assessed work • use binary search trees • you can re-use code from last semester
• read about these, now • how to build and traverse them • (possibly) more advanced ideas such as the AVL tree
and balancing trees
