EXTREME PROGRAMMING It is a new approach to development based on the development and delivery of ver y small increments of functionality.

Extreme programming relies on constant code improvement , user involvment in the development team and pairwise programming Extreme programming is the most widely used approach to agile software developme nt. Beck [Bec04a] defines a set of five values that establish a foundation for all w ork performed as part of XP, they are: Communication, Simplicity, Feedback, Cour age and Respect. In order to achieve effective communication between software engineers and other stakeholders (e.g. to establish required features and functions for the softwar e,) XP emphasizes close, yet informal (verbal) collaboration between customers a nd developers, the establishment of effective metaphors for communicating import ant concepts, continuous feedback, and the avoidance of voluminous documentation as a communication medium To achieve simplicity, XP restricts developers to design only for immediate need s, rather than consider future needs. Feedback is derived from three sources: the implemented software itself, the cus tomer and the other software team members. Beck argues that strict adherence to certain XP practise demands courage. An agi le XP team must have the discipline (courage) to design for today, recognizing t hat future requirements may change dramatically, thereby demanding substantial r ework of the design and implemented code. By following each of these values, the agile team inculcates respect among its m embers, between other stakeholders and team members, and indirectly, for the sof tware itself. THE XP PROCESS Extreme programming uses an object-oriented approach as its preferred developmen t paradigm and encompasses a set of rules and practices that occur within the co ntext of four framework activities: planning, design, coding and testing. Figure 3.2 illustrates the XP process and notes some of the key ideas and tasks that a re associated with each framework activity. In an XP process, customers are intimately involved in specifying and prioritisi ng system requirements. The requirements are not specified as lists of required system functions, rather, the system customer is part of the development team an d discusses scenarios with other team members. Together, they develop a story car d that encapsulates the customer needs. The development team then aims to impleme nt that scenario in a future release of the software. Planning: the planning activity begins with listening- a requirements gathering activity that enables the technical members of the XP team to understand the bus iness context for the software and to get a broad feel for the required output a nd major features and functionality. Listening leads to the creation of a set of stories (also called user stories) that describe required output, features, and f unctionality for software to be built Customers and developers work together to decide how to group stories into the n ext release (the next software increment) to be developed by the XP team. Design: XP design rigorously follows the KIS (keep it simple) principle. A simpl e design is always preferrred over a more complex representation. Refactoring: is the process of changing a software system in such a way that it does not alter the external behaviour of the code yet improves d internal struc ture. It is a disciplined way to clean up code and modify/simplify the internal design that minimizes the chances of introducing bugs. In essence, when you fact or you are improving the design of the code after it has been written. EXTREME PROGRAMMING PRACTICES / PRINCIPLES 1. Incremental planning- requirements are recorded on story cards and the s tories to be included in a release are determined by the time available and thei r relative priority. 2. Small releases- The minimal useful set of functionality that provides bu siness value is developed first and other functionalities are incrementally adde

d at later releases. 3. Simple design- Enough design is carried out to meet the current requirem ents and no more. 4. Test-first development- An automated unit test framework is used to writ e tests for a new piece of functionality before that functionality itself is imp lemented. 5. Refactoring- All developers are expected to refactor the code continuous ly as soon as possible code improvements are found. 6. Pair programming- Developers work in pairs, checking each others work and providing the support to always do a good job. 7. Collective Ownership- The pairs of developers work on all areas of the s ystem, so that no islands of expertise develop and all the developers own all th e code. 8. Continuous integration- As soon as work on task is complete, it is integ rated into the whole system. After any such integration, all the unit tests in t he system must pass. 9. Sustainable pace- Large amounts of overtime are not considered acceptabl e as the net effect is often to reduce code quality and medium-term productivity . 10. On-site customer- A representative of the end-user of the system (the cu stomer) should be available full time for the use of the XP team. The customer w ill responsible for bringing system requirements to the team for implementation. TESTING IN EXTREME PROGRAMMING To avoid some of the problems of testing and system validation, XP places more e mphasis on the testing process than other agile methods. There are four (4) key features of testing in XP, they are: 1. Test-first development 2. Incremental test development from scenarios 3. User involvement in the test development and validation 4. The use of automated test harnesses PAIR PROGRAMMING Is an annovative practice where programmers work in pairs to develop software. Pair programming have gained a lot of attention recently as the key software dev elopment practices of extreme programming (XP) methodology. Though development does not always involve the same pair of people working toge the. Rather, the idea is that pairs are created dynamically so that all team mem bers may work with other members in a programming pair during the development pr ocess. ADVANTAGES OF PAIR PROGRMMING 1. It acts as an informal review process since each line of code is looked at by at least two people. Code inspections and reviews are very successful in d iscovering a high percentage of software errors. 2. It supports common ownership and responsibility for the system- the soft ware is owned by the team as a whole and the team has collective responsibility for resolving the problems. 3. It helps support refactoring, which is a process of software improvement . A principle of XP is that the software should be constantly refactored. That i s, parts of the code should be rewritten to improve their clarity or structure. SOFTWARE PROTOTYPING In certain situations, due to practical or contractual reasons, an incremental s oftware delivery process cant be used. In those situations, a statement of the s ystem requirements is completed and is used by the development team as a basis f or the system software. Prototyping is the rapid devlpment of a system that seek to validate d reqmts. A prototype is an initial version of a software system that is used to demonstrat e concepts, try out design options and generally, to fiind out more about d prob lem and its possible solns. USES OF SOFTWARE PROTOTYPE IN SOFTWARE DEVELOPMENT PROCESS: 1. In the requrmt engineering process, a prototype can help in the elicitat ion and validation of system requirements.

2. It can be used to explore particular software solns and to support user interface design. 3. In the testing process, a prototype can be used to run back-to-back test s with d system that will be delivered to the customer. 4. Prototyping can be considered as a risk reduction activity which reduces requirements risks. System prototypes allow users to see how well d system supports their work. BENEFITS OF PROTOTYPING 1. Improved system usability 2. A closer match of the system to users needs 3. Improved design quality 4. Improved maintainability 5. Reduced development effort

PROTOTYPING OBJECTIVES The objective of evolutionary prototyping is to deliver a working system to endusers. The development starts with those requirements which are best understood. The objective of throw-away prototyping is to validate or derive the system requ irments. The prototyping process starts with those requirments which are not wel l understood.

EVOLUTIONARY PROTOTYPING An approach to system development where an initial prototype is produced and ref ined through a number of stages to the final system. It must be used for systems where the specifiation cannot be developed in advanc e e.g. AI syststems and user interface systems It must be based on techniques which allow rapid system iterations. Verification is impossible as there is no specification. Validation means demonstrating the adequacy of the systems. ADVANTAGES OF EVOLUTIONARY PROTOTYPING 1. Accelerated delivery of the system 2. User engagement with the system 3. Specification, design and implementation are inter-twined 4. The system is developed as a series of increments that are delivered to the customer 5. Techniques for rapid system development are used such as CASE tools and 4GLs 6. User interfaces are usually developed using a GUI development toolkit EVOLUTIONARY PROTOTYPING PROBLEMS 1. Management problems 2. Maintenance problems 3. Contractual problems THROW-AWAY PROTOTYPING A prototype which is usually a practical implementation of the system is produce d to help discover requirements problems and then discarded. The system is then developed using some other development process. Throw-away prototyping is used to reduce requirements risk. The prototype is developed from an initial specification, delivered for experime nt then discarded. The throw-away prototype should NOT be considered as a final system due to the f ollowing reasons: a. Some system characteristics may have been left out b. There is no specifications for long-term maintenance c. The system will be poorly structured and difficult to maintain

SOFTWARE REUSE Software engineering has been more focused on original development but it is now recognized that to achieve better software, more quickly and at lower cost, we need to adopt a design process that is based on systematic reuse. Reuse-based software engineering is a comparable software engineering strategy w here the development process is tailored to reusing existing software. Software reuse is in response to demands for lower software production and maint enance costs, faster delivery of systems and increased software quality. An obvious advantage of software reuse is that overall development costs should be reduced. Other advantages of reusing software assets are the: a. Increased dependability: Reused software tend to be more dependable than new software because it would have been tried and tested in working systems and its design and implementation faults would have been found and corrected. b. Reduced process risk: The cost of existing software is already known, wh ereas the costs of development are always a matter of judgment. This reduces the likelihood of error in project cost estimation. c. Standards compliance: Some standards, such as user interface standards, can be implemented as a set of standard reusable components and this improves de pendability of the system. d. Effective use of specialists: Application specialists can develop reusab le software that encapsulates their knowledge. e. Accelerated development: The system is delivered quickly to the market b ecause reusing software can speed up system production as a result of both devel opment and validation time that would have been reduced significantly. Requirements for design with reuse i. It must be possible to find appropriate reusable components ii. The re-user of the component must be confident that the components will be reliable and will behave as specified iii. The components must be documented so that they can be understood and, w here appropriate, modified. Challenges facing reuse i. Increased maintenance costs: If the source code of a reused system is n ot available then maintenance cost may be high due to the incompatible nature of the component with the change that is taking place in the environment where the system is being used. ii. Lack of tool support: Computer Aided Software Engineering (CASE) toolse t may not support development with reuse. iii. Not-invented-here syndrome: As a result of trust challenge and the fact that writing a new and original software system/component is seen as a challeng e, developers may not accept the idea of reusing software. Also it is believed t hat they can improve on the component that they rewrite by themselves. iv. Maintaining a component library: Populating a reusable component librar y and ensuring that developers can use this library may not be cost effective. v. Finding and adapting reusable components: Software components have to b e discovered in the library, understood, and sometimes adapted to work in a new environment. Its not an easy task. TECHNIQUES FOR REUSE a. Design patterns This is a description of the problem and the esence of its solution, so that the solution may be reused in different settings. The pattern is not a detailed spe cification. Rather, one can think of it as a description of accumulated wisdom a nd experience, a well tried solution to a common problem. According to Gamma et al. (Gamma, et al., 1995) there are four essential elemen ts of design patterns: 1. A name that is a meaningful reference to the pattern 2. A description of the problem area dt explains when d patter may be appli ed

3. A solution description of d parts of d design solution, their relationsh ips and their responsibilities. 4. A statement of the consequuences- the results and trade-offs - of apply ing the pattern. b. Application product lines An application type is generalised around a common architecture so that it can b e adapted for different customers. c. Component frameworks Systems are developed by integrating components that conform to component-model standards. d. Component based development Component-based software engineering relies on black-box components with defined requirements and provides interfaces. Systems are developed by integrating comp onents that conform to component-model standards. e. Legacy system wrapping Legacy systems that can be wrapped by defining a set of interfaces and providing access to these legacy systems through these interfaces. f. COTS integration Systems are developed by integrating existing application systems. COTS product reuse is concerned with the reuse of large sclae, off-the-shelf systems. These pr ovide a lot of functionality, and their reuse can radically reduce costs and dev elopment time. g. Program generators Program generators are an alternative approach to concept reuse where the reusab le concepts are embedded in a generator system. The designer specifies the abstr actions required using a domain-specific language, and an executable program is generated. h. Aspect oriented sftw development shared components are woven into an application at different places when d progr am is complied. i. Service-oriented system Systems are developed by linking shared services, which may be externally provid ed j. Configurable vertical applications A generic system is designed so that it can be configured to the needs of specif ic system customers k. Program libraries Class functions libraries implementing commonly used abstrations are available f or reuse. FACTORS TO CONSIDER WHEN PLANNING REUSE 1. The development schedule for the software: If the software need to be de veloped quickly, one should try to reuse off-the-shelf systems rather than indiv idual components. 2. The expected software lifetime: If the system usage is to span a long li fetime, then one should focus on the maintainability of the system. In this case , the long term implications of reuse should be given attention. 3. The background, skills and experience of the development team: All reuse technologies are fairly complex and you need quite a lot of time to understand and use them effectively, therefore, the development should focus on the area wh ere their strength in terms of skill lies. 4. The criticality of the software and its non-functional rqmts: For a crit ical system that has to be certified by an external regulator, you may have to c reate a dependability case for the system. RIGOROUS APPROACH TO SOFTWARE ENGINEERING To be Asked if not clear enough:Reuse based SE vs Component based SE I dont see constant refactoring(a means of software improvement as good enough) c ompared to designing for change(anticipating change in the future) which is d no

rm in conventional approaches. Refactoring means that the programming team looks for possible improvements to t he software and implement them immediately. Since it is possible improvements, it may still result in wasted effort cos d im provement may not be needed, also, in the conventional approach we are so sure o f what change we are re-building d software system for, so the re-design or re-b uilding is definitely achieving its aim (its not trial and error).