Extreme Programming Kiran Pamnany Software Engineering Computer programming
- Slides: 47
Extreme Programming Kiran Pamnany
Software Engineering ü Computer programming as an engineering profession rather than an art or a craft ü Meet expectations: ü ü Functionality Reliability Cost Delivery schedule
Methodologies ü Methodology: codified set of recommended practices ü No consensus: ü Waterfall model ü Spiral model ü Rational Unified Process (RUP) ü Extreme Programming (XP)
Classic process steps ü Requirements Analysis ü Specification ü Design and Architecture ü Coding ü Testing ü Documentation ü Maintenance
Waterfall model ü Proposed in 1970 by W. W. Royce ü Development flows through steps: ü ü ü Requirements analysis Architectural design Detailed design Coding, debugging and unit testing Integration and system testing Deployment, operation and maintenance
Waterfall model (cont. ) ü Pros: ü Track progress easily due to clear stages ü Easily identifiable milestones and deliverables ü Cons: ü Inflexible: difficult to respond to changing requirements ü Design and coding discover requirements inconsistencies ü Some problems not discovered until system testing
Spiral model ü Defined in 1986 by Barry Boehm ü Modified waterfall ü Software is developed in a series of incremental releases ü Early releases are prototypes ü Later releases become increasingly complete ü Receive feedback after each release
Spiral model (cont. ) ü Pros: ü Systematic and stepwise, but in an iterative framework ü Estimates get more realistic as work progresses ü Some ability to cope with changing requirements ü Cons: ü Time-intensive process ü Not extensively used
Rational Unified Process (RUP) ü Defined in 1997 by Grady Booch, Ivar Jacobson and James Rumbaugh ü General framework to describe specific development processes ü Designed to be tailored for a given software project with consideration for its size and type ü Recognized to be particularly applicable to large projects with large teams
RUP Phases ü Inception ü Shared understanding of the system with the customer ü Elaboration ü Architecture to build the system ü Construction ü Developing the system ü Transition ü Customer takes ownership of system
RUP Guidelines ü Develop iteratively ü Deal with changing requirements ü Address high risk items as the highest priority tasks at each iteration ü Ideally, each iteration has an executable release ü Manage requirements ü Document functionality, constraints, design decisions, business requirements ü Define use cases and scenarios
RUP Guidelines (cont. ) ü Use component architecture ü For extensibility and reusability (CORBA/COM) ü Model software visually ü Abstraction using UML ü Verify software quality ü Plan quality control and assessment ü Involve all team members ü Control changes to software ü Use secure workspaces
RUP Workflows - Typical Project (Source: George Stepanek, 2004)
RUP Criticism ü ‘High ceremony methodology’ ü Bureaucratic: process for everything ü Slow: must follow process to comply ü Excessive overhead: rationale, justification, documentation, reporting, meetings, permission
Extreme Programming (XP) ü Formulated in 1999 by Kent Beck, Ward Cunningham and Ron Jeffries ü Agile software development methodology (others: Scrum, DSDM) ü Developed in reaction to high ceremony methodologies
XP: Why? ü Previously: ü Get all the requirements before starting design ü Freeze the requirements before starting development ü Resist changes: they will lengthen schedule ü Build a change control process to ensure that proposed changes are looked at carefully and no change is made without intense scrutiny ü Deliver a product that is obsolete on release
XP: Embrace Change ü Recognize that: ü All requirements will not be known at the beginning ü Requirements will change ü Use tools to accommodate change as a natural process ü Do the simplest thing that could possibly work and refactor mercilessly ü Emphasize values and principles rather than process
XP Practices (Source: http: //www. xprogramming. com/xpmag/whatisxp. htm)
XP Practices: Whole Team ü All contributors to an XP project are one team ü Must include a business representative--the ‘Customer’ ü Provides requirements ü Sets priorities ü Steers project ü Team members are programmers, testers, analysts, coach, manager ü Best XP teams have no specialists
XP Practices: Planning Game ü Two key questions in software development: ü Predict what will be accomplished by the due date ü Determine what to do next ü Need is to steer the project ü Exact prediction (which is difficult) is not necessary
XP Practices: Planning Game ü XP Release Planning ü Customer presents required features ü Programmers estimate difficulty ü Imprecise but revised regularly ü XP Iteration Planning ü ü ü Two week iterations Customer presents features required Programmers break features down into tasks Team members sign up for tasks Running software at end of each iteration
XP Practices: Customer Tests ü The Customer defines one or more automated acceptance tests for a feature ü Team builds these tests to verify that a feature is implemented correctly ü Once the test runs, the team ensures that it keeps running correctly thereafter ü System always improves, never backslides
XP Practices: Small Releases ü Team releases running, tested software every iteration ü Releases are small and functional ü The Customer can evaluate or in turn, release to end users, and provide feedback ü Important thing is that the software is visible and given to the Customer at the end of every iteration
XP Practices: Simple Design ü Build software to a simple design ü Through programmer testing and design improvement, keep the software simple and the design suited to current functionality ü Not a one-time thing nor an up-front thing ü Design steps in release planning and iteration planning ü Teams design and revise design through refactoring, through the course of the project
XP Practices: Pair Programming ü All production software is built by two programmers, sitting side by side, at the same machine ü All production code is therefore reviewed by at least one other programmer ü Research into pair programming shows that pairing produces better code in the same time as programmers working singly ü Pairing also communicates knowledge throughout the team
XP Practices: Test-Driven Development ü Teams practice TDD by working in short cycles of adding a test, and then making it work ü Easy to produce code with 100 percent test coverage ü These programmer tests or unit tests are all collected together ü Each time a pair releases code to the repository, every test must run correctly
XP Practices: Design Improvement ü Continuous design improvement process called ‘refactoring’: ü Removal of duplication ü Increase cohesion ü Reduce coupling ü Refactoring is supported by comprehensive testing--customer tests and programmer tests
XP Practices: Continuous Integration ü Teams keep the system fully integrated at all times ü Daily, or multiple times a day builds ü Avoid ‘integration hell’ ü Avoid code freezes
XP Practices: Collective Code Ownership ü Any pair of programmers can improve any code at any time ü No ‘secure workspaces’ ü All code gets the benefit of many people’s attention ü Avoid duplication ü Programmer tests catch mistakes ü Pair with expert when working on unfamiliar code
XP Practices: Coding Standard ü Use common coding standard ü All code in the system must look as though written by an individual ü Code must look familiar, to support collective code ownership
XP Practices: Metaphor ü XP Teams develop a common vision of the system ü With or without imagery, define common system of names ü Ensure everyone understands how the system works, where to look for functionality, or where to add functionality
XP Practices: Sustainable Pace ü Team will produce high quality product when not overly exerted ü Avoid overtime, maintain 40 hour weeks ü ‘Death march’ projects are unproductive and do not produce quality software ü Work at a pace that can be sustained indefinitely
XP Values ü Communication ü Simplicity ü Feedback ü Courage
XP Values: Communication ü Poor communication in software teams is one of the root causes of failure of a project ü Stress on good communication between all stakeholders--customers, team members, project managers ü Customer representative always on site ü Paired programming
XP Values: Simplicity ü ‘Do the Simplest Thing That Could Possibly Work’ ü Implement a new capability in the simplest possible way ü Refactor the system to be the simplest possible code with the current feature set ü ‘You Aren’t Going to Need It’ ü Never implement a feature you don’t need now
XP Values: Feedback ü Always a running system that delivers information about itself in a reliable way ü The system and the code provides feedback on the state of development ü Catalyst for change and an indicator of progress
XP Values: Courage ü Projects are people-centric ü Ingenuity of people and not any process that causes a project to succeed
XP Criticism ü Unrealistic--programmer centric, not business focused ü Detailed specifications are not written ü Design after testing ü Constant refactoring ü Customer availability ü 12 practices are too interdependent
XP Thoughts ü The best design is the code. ü Testing is good. Write tests before code. Code is complete when it passes tests. ü Simple code is better. Write only code that is needed. Reduce complexity and duplication. ü Keep code simple. Refactor. ü Keep iterations short. Constant feedback.
Software Quality: Another View ü A programmer presenting an elegant but ‘inefficient’ solution, talks of the inelegant but ‘efficient’ solution ü […] but your solution doesn’t work: if the solution doesn’t have to work, then Begin. . End is a valid solution. Gerald Weinberg, ‘The Psychology of Computer Programming’, 1972
Software Quality: Another View ü […] software engineering has accepted as its charter “How to program if you cannot. ” E. W. Dijkstra, ‘The Cruelty of Really Teaching Computer Science’, 1988 ü Computer programming as a branch of mathematics--formal provability of a program is a major criterion for correctness ü Program correctness is ‘constitutional’; an incorrect program is worthless or of negative worth
Formal Verification ü The act of proving or disproving a system’s correctness with respect to a formal specification or property, using formal methods ü System types include FSM, Petri nets, timed and hybrid automata, cryptographic protocols, combinatorial circuits, etc. ü Properties to be verified are described in temporal logics; approaches include state space enumeration, abstract interpretation, etc.
Formal Methods ü Mathematical techniques for the specification, development and verification of software and hardware systems ü Classified as: ü Denotational semantics ü Operational semantics ü Axiomatic semantics
The Way Forward? ü ‘High ceremony’ software engineering methodologies in disfavor ü Agile software development methodologies in increasing use, but with significant criticism ü Formal methods will never have a significant impact until they can be used by people that don’t understand them. T. Melham
Useful tools--Testing ü Junit ü Framework to write repeatable tests (Kent Beck and Erich Gamma) ü Assertions for testing expected results ü Test fixtures to share common data ü Test runners ü Key to TDD
Useful tools--Analysis ü Insure++ (Parasoft) ü Memory debugger (accesses to freed memory, array bounds, freeing twice, etc. ) ü Inserts code ü Purify (Rational) ü Another memory debugger ü Link only ü Valgrind…
Useful tools--Analysis ü Prevent (Coverity) ü Static analysis (interprocedural data flow) ü Buffer overflow, dangling stack references, flawed branch logic, memory leaks, null pointer dereferences, use of freed/uninitialized resources, etc. ü 20% false positives
- Extreme programming in software engineering
- Computer based system engineering
- Very wide shot example
- Positive face negative face
- Kaja flash
- Neoplasms
- Kiran embedded
- Kiran ramchandani
- Financial management definition
- Define decree nisi
- Kiran abraham
- Kiran fothergill
- Kiran kaja
- Kiran mundy
- Shashi kiran shetty net worth
- Extreme programming model
- Software crisis of 1960s
- Extreme programming in agile
- Extreme programming xp ventajas y desventajas
- Extreme programming life cycle
- Diane pozefsky
- Extreme programming workflow
- Extreme point theorem linear programming
- Extreme programming advantages
- Extreme programming
- Dilbert agile programming
- Refactoring extreme programming
- Extreme programming ventajas y desventajas
- Extreme programming
- User requirements are expressed as in extreme programming
- Forward engineering in software engineering
- Software engineer vs software developer
- Toolscomp
- Computer aided software engineering tools examples
- Computer aided software testing
- Computer science software engineering
- Computer science software engineering
- Software maintenance in software engineering ppt
- What is software implementation in software engineering
- What is software metrics in software engineering
- Software crisis in software engineering
- Software metrics example
- Real time software design in software engineering
- Software design fundamentals in software engineering
- Perbedaan linear programming dan integer programming
- Greedy programming vs dynamic programming
- Components of system programming
- Linear vs integer programming