![Page 1: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/1.jpg)
1
Click to edit Master text styles Second level
Third level Fourth level
Fifth level
CSE 2311 Software Development Project
Wednesday, January 9, 2013
![Page 2: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/2.jpg)
2
NSERC Undergraduate Student Research Awards (USRA) 2013
• Information session • Friday, January 11, 1:30–2:30 • Lassonde 3033 (Comp Science & Eng building)
• Duration and value of awards • 16 weeks on a full-time basis (Apr 29 - Aug 16, 2013) • $4,500 from NSERC + at least $1,125 from the supervisor
• Application deadline • Friday, January 25, 2013, 3:00PM • See www.cse.yorku.ca/undergrad/usra/ for procedure
![Page 3: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/3.jpg)
3
NSERC Undergraduate Student Research Awards (USRA) 2013 • Eligibility
• Canadian citizens or permanent residents • Full-time students in natural sciences and engineering • Completed 18 credits of their degree program by
December 31, 2012 • A cumulative GPA of at least “B”
• Program coordinator • Prof. Burton Ma, [email protected]
• For more info • See www.cse.yorku.ca/undergrad/usra/
![Page 4: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/4.jpg)
4
Reading • Author: Ian Sommerville
• Title: Software Engineering
• Chapters 1-4
![Page 5: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/5.jpg)
5
Software Engineering
• Software Engineering is the science and art of building significant software systems that are: 1. on time 2. on budget 3. with acceptable performance 4. with correct operation
![Page 6: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/6.jpg)
6
Software Engineering • The economies of all developed nations are dependent
on software.
• More and more systems are software controlled.
• Software engineering is concerned with theories, methods and tools for professional software development.
• Software engineering expenditure represents a significant fraction of the GNP of developed countries.
![Page 7: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/7.jpg)
7
Software Costs
• Software costs often dominate system costs. The costs of software on a PC are often greater than the hardware cost.
• Software costs more to maintain than it does to develop.
• Software engineering is concerned with cost-effective software development.
![Page 8: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/8.jpg)
8
Software Products
• Generic products • Stand-alone systems which are produced by
a development organization and sold on the open market to any customer.
• Customized products • Systems which are commissioned by a
specific customer and developed specially by some contractor.
![Page 9: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/9.jpg)
9
Software Product Attributes
• Maintainability
• Dependability
• Efficiency
• Usability
![Page 10: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/10.jpg)
10
Importance of Product Characteristics • The relative importance of these characteristics
depends on the product and the environment in which it is to be used.
• In some cases, some attributes may dominate • In safety-critical real-time systems, key
attributes may be dependability and efficiency.
• Costs tend to rise exponentially if very high levels of any one attribute are required.
![Page 11: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/11.jpg)
11
Efficiency Costs Cost
Efficiency
![Page 12: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/12.jpg)
12
The Software Process
• Structured set of activities required to develop a software system • Specification • Design • Validation • Evolution
• Activities vary depending on the organization and the type of system being developed.
• Must be explicitly modeled if it is to be managed.
![Page 13: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/13.jpg)
13
Engineering Process Model • Specify: Set out the requirements and
constraints on the system.
• Design: Produce a model of the system.
• Manufacture: Build the system.
• Test: Check the system meets the required specifications.
• Install: Deliver the system to the customer and ensure it is operational.
• Maintain: Repair faults in the system as they are discovered.
![Page 14: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/14.jpg)
14
Software Engineering is Different
• Normally, specifications are incomplete.
• Very blurred distinction between specification, design and manufacture.
• No physical realization of the system for testing.
• Software does not wear out - maintenance does not mean component replacement.
![Page 15: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/15.jpg)
15
Generic Software Process Models • Waterfall
• Separate and distinct phases of specification and development
• Evolutionary • Specification and development are interleaved
• Formal Transformation • A mathematical system model is formally transformed to
an implementation
• Reuse-based • The system is assembled from existing components
![Page 16: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/16.jpg)
16
Waterfall Process Model Requirements
definition
System andsoftware design
Implementationand unit testing
Integration andsystem testing
Operation andmaintenance
![Page 17: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/17.jpg)
17
Evolutionary Process Model
Validation Finalversion
Development Intermediateversions
Specification Initialversion
Outlinedescription
Concurrentactivities
![Page 18: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/18.jpg)
18
Process Model Problems • Waterfall
• High risk for new systems because of specification and design problems.
• Low risk for well-understood developments using familiar technology.
• Prototyping • Low risk for new applications because specification and
program stay in step. • High risk because of lack of process visibility.
• Transformational • High risk because of need for advanced technology and
staff skills
![Page 19: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/19.jpg)
19
Hybrid Process Models • Large systems are usually made up of several sub-
systems.
• The same process model need not be used for all subsystems.
• Prototyping for high-risk specifications.
• Waterfall model for well-understood developments.
![Page 20: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/20.jpg)
20
Spiral Process Model
Riskanalys is
Riskanalys is
Riskanalys is
Riskanalysis Proto-
type 1
Prototype 2Prototype 3
Opera-tionalprotoype
Concept o fOperation
Simulations, models, benchmarks
S/Wrequirements
Requirementvalidation
DesignV&V
Productdesign Detailed
design
CodeUnit tes t
Integr ationtestAccep tance
testServ ice Develop, verifynext-level p roduct
Evaluate alternativesiden tify, resolve risks
Determine ob jectivesalternatives and
constraints
Plan next phase
Integrationand test p lan
Developmentplan
Requirements planLife-cycle plan
REVIEW
![Page 21: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/21.jpg)
21
Spiral Model Advantages • Focuses attention on reuse options.
• Focuses attention on early error elimination.
• Puts quality objectives up front.
• Integrates development and maintenance.
• Provides a framework for hardware/software development.
![Page 22: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/22.jpg)
22
Spiral Model Problems • Contractual development often specifies
process model and deliverables in advance.
• Requires risk assessment expertise.
![Page 23: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/23.jpg)
23
Process Visibility • Software systems are intangible so managers need
documents to assess progress.
• Waterfall model is still the most widely used model.
![Page 24: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/24.jpg)
24
Waterfall Model Documents Activity Output documentsRequirements analysis Feasibility study, Outline requirementsRequirements definition Requirements documentSystem specification Functional specification, Acceptance test plan
Draft user manualArchitectural des ign Architectural specification, System test planInterface design Interface specification, Integration test p lanDetailed design Design specification, Unit test planCoding Program codeUnit testing Unit test reportModule testing Module test reportIntegration testing Integration test report, Final user manualSystem testing System test reportAcceptance testing Final system plus documentation
![Page 25: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/25.jpg)
25
Process Model Visibility
Process model Process visibilityWaterfall model Good visibility, each activity produces some
deliverableEvolutionarydevelopment
Poor visibility, uneconomic to producedocuments during rapid iteration
Formaltransformations
Good visibility, documents must be producedfrom each phase for the process to continue
Reuse-orienteddevelopment
Moderate visibility, it may be artificial toproduce documents describing reuse andreusable components.
Spiral model Good visibility, each segment and each ringof the spiral should produce some document.
![Page 26: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/26.jpg)
26
Agile methods • Dissatisfaction with the overheads involved in design
methods led to the creation of agile methods. These methods: • Focus on the code rather than the design; • Are based on an iterative approach to software development; • Are intended to deliver working software quickly and evolve this
quickly to meet changing requirements.
• Agile methods are probably best suited to small/medium-sized business systems or PC products.
![Page 27: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/27.jpg)
27
Principles of agile methods
Principle Description
Customer involvement The customer should be closely involved throughout thedevelopment process. Their role is provide and prioritise newsystem requirements and to evaluate the iterations of the system.
Incremental delivery The software is developed in increments with the customerspecifying the requirements to be included in each increment.
People not process The skills of the development team should be recognised andexploited. The team should be left to develop their own ways ofworking without prescriptive processes.
Embrace change Expect the system requirements to change and design the systemso that it can accommodate these changes.
Maintain simplicity Focus on simplicity in both the software being developed and inthe development process used. Wherever possible, actively workto eliminate complexity from the system.
![Page 28: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/28.jpg)
28
Problems with agile methods • It can be difficult to keep the interest of customers who
are involved in the process.
• Team members may be unsuited to the intense involvement that characterizes agile methods.
• Prioritizing changes can be difficult where there are multiple stakeholders.
• Maintaining simplicity requires extra work.
• Contracts may be a problem as with other approaches to iterative development.
![Page 29: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/29.jpg)
29
Extreme Programming
• An agile development methodology
• Created by Kent Beck in the mid-90s
• A set of 12 key practices taken to their “extremes” The XP slides are based on a slide set by Daniel Baranowski
![Page 30: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/30.jpg)
30
What else is agile? • Adaptive Software Development
• Crystal Methodologies
• Dynamic Systems Development Method
• Feature-Driven Development
• SCRUM
• And others
![Page 31: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/31.jpg)
31
The 12 Practices • The Planning Game
• Small Releases
• Metaphor
• Simple Design
• Testing
• Refactoring
• Pair Programming
• Collective Ownership
• Continuous Integration
• 40-Hour Workweek
• On-site Customer
• Coding Standards
![Page 32: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/32.jpg)
32
1 - The Planning Game • Planning for the upcoming iteration
• Uses stories provided by the customer
• Technical persons determine schedules, estimates, costs, etc
• A result of collaboration between the customer and the developers
![Page 33: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/33.jpg)
33
The Planning Game – Advantages • Reduction in time wasted on useless features
• Greater customer appreciation of the cost of a feature
• Less guesswork in planning
![Page 34: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/34.jpg)
34
The Planning Game – Disadvantages
• Customer availability
• Is planning this often necessary?
![Page 35: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/35.jpg)
35
2- Small Releases • Small in terms of functionality
• Less functionality means releases happen more frequently
• Support the planning game
![Page 36: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/36.jpg)
36
Small Releases – Advantages • Frequent feedback
• Tracking
• Reduce chance of overall project slippage
![Page 37: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/37.jpg)
37
Small Releases – Disadvantages • Not easy for all projects
• Not needed for all projects
• Versioning issues
![Page 38: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/38.jpg)
38
3 – Metaphor • The oral architecture of the system
• A common set of terminology
![Page 39: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/39.jpg)
39
Metaphor – Advantages • Encourages a common set of terms for the system
• Reduction of buzz words and jargon
• A quick and easy way to explain the system
![Page 40: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/40.jpg)
40
Metaphor – Disadvantages • Often the metaphor is the system
• Another opportunity for miscommunication
• The system is often not well understood as a metaphor
![Page 41: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/41.jpg)
41
4 – Simple Design • K.I.S.S.
• Do as little as needed, nothing more
![Page 42: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/42.jpg)
42
Simple Design – Advantages • Time is not wasted adding superfluous functionality
• Easier to understand what is going on
• Refactoring and collective ownership is made possible
• Helps keeps programmers on track
![Page 43: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/43.jpg)
43
Simple Design – Disadvantages • What is “simple?”
• Simple isn’t always best
![Page 44: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/44.jpg)
44
5 – Testing • Unit testing
• Test-first design
• All automated
![Page 45: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/45.jpg)
45
Testing – Advantages • Unit testing promote testing completeness
• Test-first gives developers a goal
• Automation gives a suite of regression test
![Page 46: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/46.jpg)
46
Testing – Disadvantages • Automated unit testing isn’t for everything
• Reliance on unit testing isn’t a good idea
• A test result is only as good as the test itself
![Page 47: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/47.jpg)
47
6 – Refactoring • Changing how the system does something but not what
is done
• Improves the quality of the system in some way
![Page 48: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/48.jpg)
48
Refactoring – Advantages • Prompts developers to proactively improve the product
as a whole
• Increases developer knowledge of the system
![Page 49: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/49.jpg)
49
Refactoring – Disadvantages • Not everyone is capable of refactoring
• Refactoring may not always be appropriate
• Would upfront design eliminate refactoring?
![Page 50: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/50.jpg)
50
7 – Pair Programming • Two Developers, One monitor, One Keyboard
• One “drives” and the other thinks
• Switch roles as needed
![Page 51: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/51.jpg)
51
Pair Programming – Advantages • Two heads are better than one
• Focus
• Two people are more likely to answer the following questions: • Is this whole approach going to work? • What are some test cases that may not work yet? • Is there a way to simplify this?
![Page 52: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/52.jpg)
52
Pair Programming – Disadvantages
• http://www.cenqua.com/pairon/
• Many tasks really don’t require two programmers
• A hard sell to the customers
• Not for everyone
![Page 53: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/53.jpg)
53
8 – Collective Ownership • The idea that all developers own all of the code
• Enables refactoring
![Page 54: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/54.jpg)
54
Collective Ownership – Advantages • Helps mitigate the loss of a team member leaving
• Promotes developers to take responsibility for the system as a whole rather than parts of the system
![Page 55: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/55.jpg)
55
Collective Ownership - Disadvantages
• Loss of accountability
• Limitation to how much of a large system that an individual can practically “own”
![Page 56: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/56.jpg)
56
9 – Continuous Integration • New features and changes are worked into the system
immediately
• Code is not worked on without being integrated for more than a day
![Page 57: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/57.jpg)
57
Continuous Integration - Advantages • Reduces to lengthy process
• Enables the Small Releases practice
![Page 58: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/58.jpg)
58
Continuous Integration – Disadvantages
• The one day limit is not always practical
• Reduces the importance of a well-thought-out architecture
![Page 59: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/59.jpg)
59
10 – 40-Hour Week • The work week should be limited to 40 hours
• Regular overtime is a symptom of a problem and not a long term solution
![Page 60: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/60.jpg)
60
40-Hour Week – Advantage • Most developers lose effectiveness past 40-Hours
• Value is placed on the developers well-being
• Management is forced to find real solutions
![Page 61: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/61.jpg)
61
40-Hour Week - Disadvantages • 40-Hours is a magic number
• Some may like to work more than 40-Hours
![Page 62: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/62.jpg)
62
11 – On-Site Customer • Just like the title says!
• Acts to “steer” the project
• Gives quick and continuous feedback to the development team
![Page 63: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/63.jpg)
63
On-Site Customer – Advantages • Can give quick and knowledgeable answers to real
development questions
• Makes sure that what is developed is what is needed
• Functionality is prioritized correctly
![Page 64: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/64.jpg)
64
On-Site Customer – Disadvantages • Difficult to get an On-Site Customer
• The On-Site customer that is given may not be fully knowledgeable
• May not have authority to make many decisions
• Loss of work to the customer’s company
![Page 65: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/65.jpg)
65
12 – Coding Standards • All code should look the same
• It should not possible to determine who coded what based on the code itself
![Page 66: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/66.jpg)
66
Coding Standards – Advantages • Reduces the amount of time developers spend
reformatting other peoples’ code
• Reduces the need for internal commenting
• Call for clear, unambiguous code
![Page 67: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/67.jpg)
67
Coding Standards – Disadvantages • Degrading the quality of inline documentation
![Page 68: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/68.jpg)
68
XP – Advantages • Built-In Quality
• Overall Simplicity
• Programmer Power
• Customer Power
• Synergy Between Practices
![Page 69: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/69.jpg)
69
XP – Disadvantages • Informal, little, or no documentation
• Scalability
• Contract Issues
• Misconception on the cost of change
• Tailoring
![Page 70: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/70.jpg)
70
Application – Advantageous • Highly uncertain environments
• Internal projects
• Joint ventures
![Page 71: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/71.jpg)
71
Application – Disadvantageous • Large, complex environments
• Safety critical situations
• Well understood requirements
• Distant or unavailable customer
![Page 72: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/72.jpg)
72
Web resources • www.junit.org
• www.xprogramming.com
• www.extremeprogramming.org
• www.refactoring.com
• www.pairprogramming.com
![Page 73: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/73.jpg)
73
Our project • Fully develop a system that translates guitar tablature
from ASCII to PDF
• We will call it TAB2PDF
• We will use an extreme programming approach whenever possible
![Page 74: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/74.jpg)
74
ASCII Tablature
![Page 75: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/75.jpg)
75
PDF Tablature
![Page 76: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/76.jpg)
76
To get started • Look at the sample input and output files posted on the
course website
• Download the iText library for dynamically creating PDF files • http://itextpdf.com
• Attempt to create a Hello World PDF file
• Lots of examples at the site above
![Page 77: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/77.jpg)
77
Intentionally vague requirements • In a real software development project, requirements
are vague and ever-changing
• The exact requirements will be refined iteratively by meeting with the “customer” on a weekly basis
![Page 78: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/78.jpg)
78
Teams • Teams are assigned randomly by the “manager”
• As enrollment in the course changes in the first few weeks, the “manager” will rearrange the teams
• Same as a real software project!
![Page 79: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/79.jpg)
79
Team 1 • Chayka, Dmytro
• D'Costa, Ryan
• Mangal, Alistair
• Pilay, Jorge
![Page 80: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/80.jpg)
80
Team A • Carr, Matt
• Choi, Youn
• Dutta, Dev
• Vieira Leite, Guilherme
![Page 81: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/81.jpg)
81
Workload • This course requires 8-10 hours per week per student
• Have to start working immediately
• In the second hour of each lecture, each team will present their progress to the instructor and receive feedback • “Customer” on site!
![Page 82: New Week1 · 2013. 1. 9. · • Normally, specifications are incomplete. • Very blurred distinction between specification, design and manufacture. • No physical realization of](https://reader035.vdocuments.us/reader035/viewer/2022071218/604f2328f053106036380699/html5/thumbnails/82.jpg)
82
Evaluation • 15% - Midterm prototype + Presentation (due Mar 6)
• 10% - Requirements Document (due Apr 8)
• 10% - Design Document (due Apr 8)
• 10% - Testing Document (due Apr 8)
• 5% - User Manual (due Apr 8)
• 20% - Evaluation of final code (due Apr 8)
• 20% - Final presentation (due Apr 3)
• 10% - Participation (in class and at weekly presentations)