csc444h: so(ware engineering I matt medland [email protected] http://www.cs.utoronto.ca/~matt/csc444
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
csc444h: so(ware engineering I
matt medland
[email protected] http://www.cs.utoronto.ca/~matt/csc444
about me
• undergrad in computer science • graduate student here…twice! • mix of academic & industry background
– approximately 40% / 60% split • developer, manager, director, consultant,
chief software architect • small startup up to company of 4000+ • mainframe, desktop, web, cloud, mobile,
embedded
your TAs
• Narges Norouzi – [email protected] – Ph.D. candidate
• Nitin Guleria – [email protected] – MEng. candidate
about the course
• home page: – h7p://www.cs.utoronto.ca/~ma7/csc444 – syllabus & marking scheme – course announcements – assignments – lecture slides will be posted aCer each session – link to forum on piazza – etc.
about the course (2)
• textbook – “The Agile Planning Horizon in Professional So3ware Development”, by David A. Penny, Ph.D.
– supplemental material provided on course page
about the course (3)
• lectures, tutorials, labs, office hours – lec: monday 3-‐6 in WB219 – lab: T3-‐6 & F3-‐6 – GB251
• no lab this week – tut: T2 – BA3012, F11 – BA3008
• no tutorial this week – o/h: monday 2:00 p.m. BA5224
about the course (4)
• evaluation
course evalua+on
labs & assignments 30%
midterm 20%
final exam 40%
par-cipa-on 10%
about the course (5)
• topics chosen from: – advanced UML, pa7erns, architecture, refactoring, soCware evolu-on, reverse eng., SDLC models, project mgmt. (planning, risks, es-ma-on, priori-za-on), requirements analysis, v&v, tes-ng, quality, managing a team, formal methods, etc.
– some topics will get more a7en-on than others
about the course (6) • this course teaches you professional software
development practices. – deals mostly with process and related tools, rela-vely li7le with specs/
designs/coding – if you have the ap-tude and inclina-on of becoming a professional soCware
engineer you will find the course interes-ng.
• applying these practices will help you avoid: – missed dates – defect-‐ridden soCware – badly-‐designed features – poor architecture leading to high maintenance costs – dysfunc-onal professional rela-onships between “the business side” and
soCware development (or R&D)
• when software is built in a professional fashion in industry, this (more or less) is how it is consistently done.
course policies
• re-grading – requires written request to instructor with explanation – will be done by the Instructor, mark may go up or down!
• late assignments – due date/-me posted on the assignment and webpage – daily penal-es will apply to late work (10% per day, up to 7
days, then a mark of 0 will be assigned)
• academic integrity – don’t plagiarize. ok to discuss, but don’t take notes. – properly site sources in your reports
• communication – only email me if it’s confiden-al – put csc444h in subject – use discussion forum for ques-ons, answer other’s ques-ons!
• par-cipa-on mark includes forum!
why do we need a course on engineering so(ware systems?
moBvaBon
moBvaBon (2)
• historically, humans are very bad at engineering large software systems – see “why software fails” under readings
• how bad can we be? software is everywhere! some of us must be ok at it…right?
• annually, $bn are wasted on failed or over-budget large software projects. – lots of room for improvement!
moBvaBon (3)
• national programme for IT in the NHS (UK national health service) NPfIT: – cancelled project took 9 years and cost £12bn – from computerworlduk.com, 11/09/2011:
“The [UK] government will formally announce the scrapping of the National programme for IT in the NHS…to “urgently dismantle” the health service IT scheme comes after a series of damming reports…The final nail in the £12 billion scheme will be announced this morning…set up in 2002, is not fit to provide services to the NHS. ‘There can be no confidence that the programme has delivered or can be delivered as originally conceived,’”
moBvaBon (4)
• is it because they didn’t use agile? • agile projects can fail too! and just as bad
– universal credit is Bri-an’s plan to consolidate all welfare payments into one.
– touted as the world’s biggest agile soCware project, now close to total failure!
– original budget = £2.2bn, cost so far = £12.8bn – ar-cle:
h7p://news.slashdot.org/story/13/05/25/139218/worlds-‐biggest-‐agile-‐soCware-‐project-‐close-‐to-‐failure
• I bet the welfare recipients could have used that £12.8bn!
moBvaBon (5)
race condition on computer system in Ohio caused stalling of audio/visual alerts primary system failed, then shortly after, the backup also failed (d’oh!)
2003 blackout
moBvaBon (6)
$500m for a website? are you serious?!?!
healthcare.gov
moBvaBon (7)
• author of Why Software Fails states that:
"Studies indicate that large-‐scale projects fail three to five -mes more oCen than small ones.”
• article: h7p://spectrum.ieee.org/compu-ng/soCware/why-‐soCware-‐fails
what is large?
• lots of talk about “large” systems • what do we mean when we say a software
system is “large?” – class discussion – some examples – largest soCware you have ever worked with?
what is large? (2)
• what makes a software system “large?” – kloc?, “what about comments?”, ok, fine, executable statements when compiled?
– number of bytes? – person-‐hours, or some other effort metric? – number of developers? – number of features? – number of processors running the code? – number of users of the soCware? – number of bugs?
what is large? (3)
– size of the box? number of floppy disks, and hours it takes to install it? J
what is large? (4)
• answer (well at least my answer): – something that is not a “spike” and is intended for users other than developer – released
– can benefit from, and is not hindered by, proper prac-ces (modeling, source control, automated unit tes-ng, con-nuous integra-on…)
– standard development tools are not too cumbersome (ex. making an eclipse project is overkill => not “large” for our purposes)
– so, basically anything non-‐trivial
summary
• this course deals with the challenges of major software projects – working with legacy code/systems – analyzing problems – deciding what is feasible, with the given team, and the amount of -me available
– managing next release development – delivering quality soCware in a professional soCware environment
10 minute break!
so(ware engineering
• it’s all about matching process, tools, technology, and architecture to your situation. – 40 line throwaway python script for your own use
• only you will use it • only you will contribute to it • you will use it for the next 30 minutes and never again
– a soCware product you are building a company around
• 10’s of thousands of paying customers will use it • eventually a large team will collaborate on it • it will survive for > 10 years
– and everything in between • there is no one “right way” for any situation
new vs. established product
• new product – 1 yr. to develop – 3 coders, 1 tester, 1 documenter – cost = 1 x 5 x $100,000 = $500,000
• established product – 5 years later – 20 coders, 10 testers/build, 5 documenters – cost to date = $10,000,000 – ongoing cost = $3,500,000 / year
• improve productivity by 10% – new product: save $50,000 – Established product: save $1,000,000 to date, $350,000/year
new vs. established (2)
• next release development is more economically important.
• learn how ‘next release’ is done to setup initial release properly
top-‐10 essenBal pracBces
• crystallized for me whenever I enter into a new engagement. • if any of these are missing, I know I have something to fix. • these are all important • it will take more than this course to cover them all • you will agree that all suggestions are sensible and will
probably vow to carry them out – on your first job, you’ll focus on code and test and forget most of them – you’ll be bi7en in the ass – you’ll re-‐commit to the ideas (if you’re good)
• simple but hard – trust me: make sure these things are done and everything will go ok – very hard to change behaviour – need to be dogged and determined and tricky
• geared more towards ‘next release’ than ‘new release’
top-‐10 (2)
infrastructure
control
refinement
source code control
defect/feature tracking
reproducible builds
automated regression
testing
Agile Horizon Planning
feature specifications architectural
control
business planning
effort tracking process
control
top-‐10 (3)
infrastructure
control
refinement
source code control
defect/feature tracking
reproducible builds
automated regression
testing
Agile Horizon Planning
feature specifications architectural
control
business planning
effort tracking process
control
1. source control
• central repository – everybody knows where to find what they are looking for – secure, backed-‐up storage
• defines module architectural structure – Hierarchy
• complete change history – can back up and find where problems are first introduced
• multiple maintenance streams – work on next release while maintaining previous releases
• patches – Can go back and patch any release in the field
• Enables team development • “interface” to coordinate dev and QA/build • “guard” against bad changes
2. issue tracking
• keeps track of all defects found or new features desired – won’t forget any
• coordinates a workflow for writing / fixing them – won’t skip steps
• provides management visibility into progress and enables metrics to be gathered
• enables effective prioritization
3. reproducable builds
• check out of source control and one command to build the product
• required for a consistent experience across all developers, QA/Build, customers
• dev builds – for coding and tes-ng
• production builds – includes crea-on of install image – and crea-on of ISO-‐Image (if s-ll shipping on round things) – should also be fully automated
4. automated regression tesBng
• scripts that run after every QA/Build dev build to test as much functionality as possible
• critical to improving software quality
• prevents errors with previously seen symptoms from recurring – a very common thing to happen
• enables coders to change tricky bits with confidence
• enables finding problems closer to their injection – earlier you can find an issue the less costly it is to fix.
regression tesBng (2)
• enables fixing last problems prior to shipping
with confidence – can release with fewer known defects – can release on -me
• includes automated unit testing – developed while code is being wri7en – tests classes and modules (collec-ons of classes). – good design + dependency injec-on to replace surrounding
infrastructure without recoding
infrastructure
control
refinement
source code control
defect/feature tracking
reproducible builds
automated regression
testing
Agile Horizon Planning
feature specifications architectural
control
business planning
effort tracking process
control
5. horizon planning
• after the previous basics are in place this is the most important practice – will spend rela-vely more of the course on this
• determining – what goes into the soCware – by when will it will be done – using what resources
• tracking that throughout the time horizon
• adjusting as necessary
horizon planning (2)
• enables business side to do their jobs – good rela-onships
• enables quality – by maintaining necessary non-‐coding periods (e.g., stabiliza-on
sprints)
• provides elbow room
– to improve produc-vity
• a weakness of many agile methods – end date prediction is somewhat an undefined thing!
release planning
• book used to refer to this as “release planning” – you may find older references to that.
• while the “big bang” release is still used and important, a lot of us are releasing software much more continuously. – used to be a horrible cowboy hacker sort of thing – if following good prac-ces is now a preferred method, especially
for SoCware-‐as-‐a-‐Service
• it is still critical to plan what features will be released by when over a convenient time horizon (e.g., 6 months, or quarterly) – when code gets pushed to produc-on is a detail – how customers are presented with the new features is a detail – all the “release planning” principles used for big bang releases s-ll
apply
6. feature specificaBons
• complicated features require them – need to make this determina-on
• needed to keep release plan on track – be7er es-mates if know what we are doing in more detail
• enables a better end-user feature • eliminates unanticipated integration problems • best place to introduce reviews
• The agile approach is to develop smaller units of user-visible functionality, and have constant user input. – somewhat suspect
7. architectural control
• must maintain a clean architecture even in the face of – many coders working on the code – frequent feature addi-ons
• that the soCware was not designed for ini-ally – frequent defect correc-ons
• by inexperienced coders who do not understand the architecture
architecture (2)
• architectural documentation • review of designs and code for conformance • chief architect (CSA) • automated architectural checking tools
• agile approach is not to document the architecture. the code should be sufficiently well-designed that the architecture is clear. – somewhat suspect
infrastructure
control
refinement
source code control
defect/feature tracking
reproducible builds
automated regression
testing
Agile Horizon Planning
feature specifications architectural
control
business planning
effort tracking process
control
8. effort tracking
• need to know how much staff time is spent on – each new feature – correc-ng defects – Other
• can improve estimation accuracy • can improve estimates of staff time available
for next release • can monitor effectiveness of initiatives to free
up coder time for more coding
effort tracking (2)
• agile approach fixes the sprint length (e.g., 10 days), and looks at the number of “units” that were accomplished during that time. that establishes the number of “units” available for the next sprint of the same duration (velocity). – simple to implement – can’t really say “why” and improve prac-ces as a result – managers don’t trust “units”
9. process control
• written process for the release cycle • gets everybody on the same page
– can train new staff
• enables systematic definition / collection of metrics
• can monitor process for compliance • can consider changes to the process from
a stable baseline
10. business planning
• development occurs within a business context
• if not understood and managed, will sink the project more surely than technical shortcomings
• writing effective proposals
• integrating into the budget cycle.
• (may not have to cover this year)
infrastructure
control
refinement
source code control
defect/feature tracking
reproducible builds
automated regression
testing
Agile Horizon Planning
feature specifications architectural
control
business planning
effort tracking process
control
Related Documents
