Software Engineering G6046
Dr Kingsley Sage
Copyright By PowCoder代写 加微信 powcoder
Contact me
• Dr Kingsley Sage
• Office: Chichester CI-302
• E-mail: • E-mail if you need to see me
Teaching assistant
• Teaching assistants: and
• They will be taking the lab/seminar sessions
• Will be supervising team work, monitoring attendance
• We will also be having some special seminar events
Text Books
– Software Engineering – (10th Edition)
• Copies available in library
• Various earlier editions also
– They will probably do for most of the module content
• Website is very useful – Slides, exercises etc.
Use the text book
• Some of the lecture content is based on sections from the book
• If you are not a native English speaker
– Might help to read some of the chapters before the lecture
• If you are a native English speaker – It will still help
Supplementary text
• 2 hours of lectures a week – Mondays 3-4 Arts A002
– Fridays 11-12 Arts A002
Module structure
• Lectures in weeks 1-10 (approx.)
• Labs/seminars in weeks 4-11, a mix of: – Project support (mostly)
– Discussions
– Exercises
– All intended to support your coursework
• Guest lectures/activities
Assessment
• 67% coursework (group project) • 33% unseen examination
Coursework
• Substantial programming project • Working in teams
• You will be assigned to a team
– You have one week to form a firm team
– Or you will be assigned to a team
– Proportion of your marks by “peer marking”
So what is Software Engineering all about
• It’s not all about programming …
If you are a confident coder …
• This may be frustrating to you
• Your code skill of coding plays only a part of the activity of this module
• And if may not get the recognition you think it deserves …
If you are not a confident coder
• This might just show you how much of computer science isn’t about programming
• There are other things to do as well
• In this module we shall be looking at them
Programming by yourself
• Probably the vast majority of software you developed up to now was …
– Coded by you alone
– Potentially in competition with other people
– Contained enough to be constructed in “just a few” development sessions
Not all software projects are like that
• In fact, most of them are not. – Large
– Long lived
– Collaborative
– Maintained by teams rather than by individuals
This is very, very hard
• Often problems arise regardless of the quality of the actual code
• And when it happens it can be very, very bad
• And very, very expensive …
So what can we do?
• No perfect answer
• But we can adopt some principles to try to make some problems more avoidable
Software Engineering
• Processes
• Shared language
• Common notation
• Structured development activities
Several different approaches
– Plan based – “Waterfall”
• More recent
• More adaptable
• Much more trendy
• But a great deal harder to do • And harder still to get right
So, for now …
• Consider plan based methods
• Try to do some Agile
• Many practical projects adopt hybrid approaches
Plan based – documents
• Requirements analysis
• Quality and Quality Assurance
Requirements analysis
• Statement of what the system has to do in order to operate satisfactorily
• Checklist of necessary features
• (some) analysis of the structure of the task, and decisions on appropriate abstractions and reuse
• Very little of this whole process involves any coding
• Instead:
– Group work
– About communication
– About teamwork
– An art as much as a science
Advantages of plan based
• Easier for everyone to follow
• Documentation gives external clients reassurance that things are proceeding
• Fairly simple to manage
Disadvantages
• Bureaucratic
– Many documents well suited to knocking out small animals
• Inflexible
– Requirements often change between analysis and deployment
• Long delay before the software is deployed
• Talk more about this in a later session
• A process that leads to incremental delivery in a series of sprints
Property Tycoon
• A version of the popular board game Monopoly
• Fully featured game for players to enjoy
• But with the option of autonomous players
• Autonomous players will need to have a play strategy
Property Tycoon
• The project will require:
– Decoding the user requirements (they will appear on Canvas very soon)
– Building and testing a working system using a form of Agile development…
• The focus is on Software Engineering as much as the coding
What you will need to do
• At least once a week you will meet to review progress
– In your seminars (may not be easy to arrange)
– Some weeks you may be asked to give a short presentation of progress at the seminar sessions
• You will need to meet up regularly and between seminar sessions
Peer marking
• At the end of the module you will need to agree a peer assessment for your team
• Each team has a pool of 20 x (number of members) marks. This needs to be assigned by agreement of all team members
– Entirely acceptable for all members to receive the same mark
– Total mark must add to the required total
– It is your responsibility to reach an agreed position. I reserve the right to impose a settlement on any team that does not reach an agreed position
– The peer marking component will be scaled so that a score of 20 makes up 10% of the total coursework grade
Team roles
• Consider what role you think you would like to take on. There are many interesting possibilities:
– Analysis
– Programming
– Quality assurance and testing
Getting started
• Don’t wait until week 4 to do anything. The way to succeed is to make early progress and gain momentum as a group
• The project will be built in a series of Agile sprints with incremental objectives
• Your TAs and I will be available via email or forum between timetabled contact times
Considerations
• The project is not especially difficult to actually code (it’s not complex) but it is complicated – there are lots of different bits to fit together
• Don’t waste time wondering where to begin – just jump right in and don’t be afraid to make mistakes
• Those of you who are confident programmers – don’t get carried away as the first idea you have may not prove to be the best choice in the long run – be prepared to self- evaluate and listen to feedback from others
• Those of you who are not confident programmers – engage with what is happening at the code level and don’t just silo yourself in an admin only role
Final thoughts on the project
• This is potentially the largest single project you have worked on to date
• Respect the challenge, but don’t be frightened of it
• Teamwork can be difficult
• It is likely that you will have team members who will act in a problematic way
• Your grade depends to a surprisingly large extent on the work of other group members
• It is possible that some groups will have members drop out. if this happens we reserve the right to amalgamate small group
• First-hand experience of how teams can fail, often for social rather than technical reasons, and reflecting on how to avoid this happening is an important learning outcome of this module
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com