Software Engineering - Distilled Preface God cursed a few to have eternal suffering.

They started learning software engineering Software Engineering is a recognized as a subject worthy of serious research, conscientious study, and tumultuous debate. Throughout the industry, software engineer has replaced programmer as the job title of preference. Software process models, software engineering methods, and software tools have been adopted successfully across a broad spectrum of industry applications. Although managers and practitioners recognize the need for a more disciplined approach to build and use software, most of the real time practices are not noteworthy. Many individuals and companies develop software haphazardly irrespective of the nature of the technology they are using. As a result quality of the software suffers to a great extent. Many people argue about the practical difficulties of teaching software engineering. Organizations that are developing software are unaware of the text book practices, academic institutions which are preaching software engineering are unaware of real time practice. Due this distinct nature, the subject software engineering is proposing a great challenge to its learners especially to know the impact of software engineering practices. Here the so called difficulty of teaching an align concept can be nullified by simulating a real time scenario in which more complex issues regarding software engineering can be addressed. This distilled lecture notes on software engineering is created basically to serve as a guide to clear the semester examination and to reduce the fear that is arises which arises due to learning research oriented papers. Though the notes are created with examination in mind, the contents will definitely give a comprehensive introduction to students of upper level of graduates. The notes can be more effective if it used along with the lecture presentations. A wide variety of software engineering books and downloaded lecture notes and were used to create(!) this book along with the official text book, Software Engineering, Roger S. Pressman, Sixth edition. The first chapter gives a detailed description of software engineering and the subsequent chapters are created with questions and answer to practically reduce the struggle of find what should be given as an answer to a specific question.

Chapter 0 Getting Started With Software Engineering 0.0 Why Software Engineering ? Computer software has become a driving force. It is the engine that drives business decision making. It serves as the basis for modern scientific investigation and engineering problem solving. It is a key factor that differentiates modern products and services. It is embedded in systems of all kinds: transportation, medical, telecommunications, military, industrial processes, entertainment, office products, the list is almost endless. Software is virtually inescapable in a modern world. And as we move into the twenty-first century, it will become the driver for new advances in everything from elementary education to genetic engineering. In the last seven years, the role of software as the driving force has become even more obvious. A software-driven Internet has spawned its own $500 billion economy. In the euphoria created by the promise of a new economic paradigm, Wall Street investors gave tiny dot-com companies billion dollar valuations before these start-ups produced a dollar in sales. New software-driven industries have arisen and old ones that have not adapted to the new driving force are now threatened with extinction. The notion of Software engineering was first proposed in 1968 at a conference held to discuss what was then called the software crisis. The crisis here refers to a number of informal software engineering methods used to develop software were not good enough. Most of the projects were sometimes years late. The software cost much more than predicted, was unreliable, was difficult to maintain and performed poorly. As the importance to software, its quality and the companies have grown, the software community continually attempts to do more research for developing technologies that will make high quality computer programs in a easier, faster and less expensive way. But the fact about developing such quality application is there are many successes and too many failures. Some of these technologies are targeted at a specific application domain (e.g., Web-site design and implementation); others focus on a technology domain (e.g., object-oriented systems); and still others are broad-based (e.g., operating systems such as LINUX). However, we have yet to develop a software technology that does it all, and the likelihood of one arising in the future is small. The software engineering technology encompasses a process, a set of methods and an array of tools that we call software engineering. No single ideal approach to software engineering is enough to build quality software. A diversity of approaches is required due to different types of organizations and systems. However fundamental notions of process systems underlie all these techniques and that is the essence of software engineering.

Software engineering can be rightly proud of their achievements. Without complex software we would not have explored space, would not have the Internet and modern telecommunications and all forms of travel would be more dangerous and expensive. Software engineering has contributed to a great deal and its contributions to the 21 st century will be even greater.

0.1 Software The text book description of the software might take the following form: (1) Software is instructions that when executed provide desired function and performance (2) Documents that describe the operations and the use of the programs; For our convenience, we can use the following definition A computer program or a collection of programs and associated documentation Software is Classified in two broad categories. Generic - developed to be sold to a range of different customers Apache Xerces Custom - Developed for a specific client according to their specification - Web pages, Depts e-admission

0.2 Software Engineering The History

In 1968, Edsger Dijkstra wrote about the harmful effects of the goto statement. A conference in 1968, sponsored by the NATO Science Committee addressed the software crisis and introduces the term software engineering. Software engineering processes and Methodologies evolved with Waterfall model to avoid haphazard software development. 0.3 Software Characteristics To gain an understanding of software some of its characteristics need to be examined 1. Software is developed or engineered, it is not manufactured in the classical sense. Software can not be manufactured like any other products. It must be engineered or developed systematically by applying a number of methods and processes. Quality is achieved by following a number of steps or methods than simply manufacturing. Constructing a product with a different approach. Managing the software projects require exclusive skills and they cant be matched with any other product manufacturing skills.

2. Software does not wear out. Only the hardware begins to wear out due to dust, vibration, abuse, temperature extreme and environment maladies. Software will suffer only from undiscovered errors. These errors should be corrected, without introducing new errors. As the day progresses the software will deteriorate and wont wear out . 3. Although the industry is moving toward component-based assembly, most software continues to be custom built. A software component must be designed in a way that it can be reused in many different programs. Custom built are software that can not be reused. Though the industry is interested to develop more generic software, the majority of the development continues to be custom built and component reuse is not yet a natural part of engineering process. What is deterioration? In it is lifetime, a software will undergo change. Such changes introduce errors and they will be corrected and new errors will be introduced. At one point of time the software may require lot of changes and the failure level of the software begins to raise. This will make the software deteriorates.

0.4 Software Applications It is somewhat difficult to develop meaningful generic categories for software applications. As software complexity grows, neat compartmentalization disappears. The following software areas indicate the breadth of potential applications:

System software. System software is a collection of programs written to service other programs. Some system software (e.g., compilers, editors, and file management utilities) process complex, but determinate, information structures. Other systems applications (e.g., operating system components, drivers, telecommunications processors)

Business software/Application Software . Business information processing is the largest single software application area. Payroll, accounts receivable/payable, inventory have evolved into management information system (MIS) software that accesses one or more large databases containing business information.

Engineering and scientific software. Engineering and scientific software have been characterized by "number crunching" algorithms. Applications range from astronomy to

volcanology, from automotive stress analysis to space shuttle orbital dynamics, and from molecular biology to automated manufacturing. Embedded software. Embedded software resides in read-only memory and is used to control products and systems for the consumer and industrial markets. Embedded software can perform very limited functions (e.g., keypad control for a microwave oven) or provide significant function and control capability (e.g., digital functions in an automobile such as fuel control). Product line software. Word processing, spreadsheets, computer graphics, multimedia, entertainment, database management, personal and business financial applications, external network, and database access are some examples for personal computer applications. Web apps. The Web pages retrieved by a browser are software that incorporates executable instructions (e.g., CGI, HTML, Perl, or Java), and data (e.g., One of the most comprehensive libraries of shareware/freeware can be found at www.shareware.com). Artificial intelligence software. Artificial intelligence (AI) software makes use of nonnumerical algorithms to solve complex problems that are not amenable to computation or straightforward analysis. Expert systems, also called knowledge based systems, pattern recognition (image and voice), artificial neural networks, theorem proving, and game playing are representative of applications within this category. Ubiquitous Computing. The rapid growth of wireless networking has made a way to the development of software applications that allow small devices, personal computers and enterprise system to communicate across vast networks. Netsourcing. The software applications that run on the web to provide simple and sophisticated functions to web end-users. Open Source. A growing trend that results in distribution of self descriptive source code for system applications is called opens source. The open source applications may range from operating systems, databases development environments, etc., They allow customers to make local modifications.

0.5 Software Engineering Myths Today, most knowledgeable professionals recognize myths for what they are misleading attitudes that have caused serious problems for managers and technical people alike. However, old attitudes and habits are difficult to modify, and software myths are still believed. There are three types of myths. Management Myths. Managers with software responsibility, like managers in most disciplines, are often under pressure to maintain budgets, keep schedules from slipping,

and improve quality. Like a drowning person who grasps at a straw, a software manager often grasps at belief in a software myth, if that belief will lessen the pressure (even temporarily). Myth 1 : A book full of standards and procedures is enough to build quality software Reality : Though they are available, they are not properly applied. Myth 2 : Add more people if project gets delayed Reality : Adding more people to a late project will make it later Brooks law Myth3 : Outsourcing will help, we can relax Reality : If you are not able to manage and control, you will struggle Customer Myths. A customer who requests computer software may be a person at the next desk, a technical group from the Technology park, the staffs of your own department or an outside company that has requested software under contract. In many cases, the customer believes myths about software because software managers and practitioners do little to correct misinformation. Myths lead to false expectations (by the customer) and ultimately, dissatisfaction with the developer. Myth 1: A general statement of the objectives is sufficient to start programming Reality : Comprehensive statement is not possible, clear and unambiguous requirements are required Myth 2: Change can be easily accommodated, because s/w is flexible Reality : true, but should be requested early or major design has to be modified Practitioner's Myths. Myths that are still believed by software practitioners have been fostered by 50 years of programming culture. During the early days of software, programming was viewed as an art form. Old ways and attitudes die hard. Myth 1: Once we write the program and get it to work, our job is done Reality : 60-80 % effort is required only after the product is delivered Myth 2 : Until I get the program running, quality cant be assessed Reality : QA and Formal technical reviews are enough to do quality filtering Myth 3: Working program for a successful project is the only deliverable

Reality : Documentation play a very important role since it is the foundation and guideline Myth 4: SE will make as create unnecessary documentation Reality: SE is not about creating documents, its about creating quality software

Chapter 1 The Process 1.0 Software Process What exactly is a software process from a technical point of view? Within the context of this notes, we define a software process as a framework for the tasks that are required to build high-quality software. Software processes are adapted to meet the needs of software engineers and managers as they undertake the development of a software product. Is the word process synonymous with software engineering? A software process defines the approach used to build a software when it is engineered. But software engineering encompasses technologies that populate the processtechnical methods and automated tools. Define the term Software Engineering. Hundreds of authors have developed personal definitions of software engineering. For our convenience we use the following definition of IEEE. Practical application of scientific knowledge to the design and construction of computer programs and their associated documentation required to develop, operate and maintain them What are process, methods and tools ? Any engineering approach must depend on organizational commitment to quality. There are a number of ways to ensure software quality and all ways ultimately leads to developing more quality approaches to software engineering. What are work products ? The software engineer's work products (programs, documentation, data) are produced as consequences of the activities defined by the software process. What are the technological layers of software engineering ? The foundation for software engineering is the process layer. Software engineering process is the glue that holds the technology layers together and enables quality and and timely development of computer software. Process defines a framework for a set of key process areas (KPAs) that must be established for effective delivery of software engineering technology.

What is KPA ? The key process areas are important to establish the context in which technical methods are applied, work products (models, documents, data, reports, forms, etc.) are produced, milestones are established, quality is ensured, and change is properly managed. What are methods ? Software engineering methods provide the technical how-to's for building software. Methods encompass a broad array of tasks that include requirements analysis, design, program construction, testing, and support. What are tools ? Tools are used to support processes and methods. A tool or system that supports software development is called Computer Aided Software Engineering (CASE). What is CASE ? CASE combines software, hardware, and a software engineering database (a repository containing important information about analysis, design, program construction, and testing) to create a software engineering environment conducive for software development.

Diagram 1.0 - Software Engineering A Layered Technology 1.1 The Software Process A Process Framework A common process framework is established by defining a small number of framework activities that are applicable to all software projects, regardless of their size or complexity. A number of task setseach a collection of software engineering work tasks, project milestones, work products enable the framework activities and umbrella activities such as software quality assurance, configuration management, measurement overlay the process. Note: The umbrella activities are independent of the framework activities and occur through out the process.

Diagram 1.1 - Framework Activities and Umbrella Activities What are framework activities? The following are the framework activities, applicable to all software projects regardless of their size and complexity. 1. Communication - with customers, encompasses requirement gathering 2. Planning - tasks, risks, resources, products and work schedule 3. Modeling - (Analysis & Design) to better understand the requirements and a design to achieve them 4. Construction - Coding and Testing 5. Deployment - Delivering the working program and receiving the feed back What are the umbrella activities? 1. 2. 3. 4. 5. 6. 7. 8. Software configuration management manages the effects of change Document preparation and production creating models, docs., logs, forms, lists Reusability management -define criteria and establish mech. to reuse Software project tracking and control asses progress Risk Management - assess risks that affect quality Software quality assurance activities to ensure quality Formal Technical Reviews assess product to uncover and remove errors Measurement - collect product and process measures to assist the development team

1.2 CMMI It is a model, intended to help organizations identify best practices and enhance the maturity of their development process. Basically it is a process improvement model developed and published by Software Engineering Institute. The evolution of CMM is CMMI project. CMMI has five stages. Deployed by organizations across the world. The two representations staged and continuous are based on the nature of the organization adopting that model. Every organization should develop a process model which conforms to the CMMI guidelines. The goal of the CMMI project is to improve usability of CMM for software engineering and other disciplines, by integrating all the different models into one model. The Standard CMMI Appraisal Method for Process Improvement (SCAMPI) is the only appraisal method to appraise companies. 1.2.0 Representation Each process area (eg. Req. gathering) is assessed against specific goals and is rated according to the following levels Level 0 - Incomplete No goals achieved Level 1 Initial all are completed Level 2 - Managed all are completed + conform to a product or project Policy Level 3 - Defined - all are completed + conform to an organizational policy Level 4 - Quantitatively Managed - all are completed + policy measured and controlled - quantitatively Level 5 Optimized Continuous process improvement An organization may choose improve process using either 1. Process Capability approach Continuous representation 2. Organizational Maturity approach Staged representation 1.2.1 CMMI - Points to Ponder CMMI provides a proven sequence for adopting improvements, beginning with basic project management practices Maturity levels in CMMI provide a simple benchmark for comparison of organization capability with prior performance or that of other organizations Staged representation provides an easy migration from SW-CMM to CMMI 1.3 Patterns Patterns are used to define activities, actions, work tasks, work products. They provide a template - for describing important characteristics of a software process. They contain the following:

 Describes a complete process (eg. RAD) An important framework activity (eg. Planning) A task within framework activity (eg. Cost estimation) The Amblers template to describe process patterns is a meta template - a template for a template. That is the Amblers template describes about the details that must appear in a process template. The following list comprises of the things that must be in a process template. Name Intent - Brief Objective of the process - Text and Diagrams if required Type - Phase Patterns Defines Sequence of Frame work activities eg. RAD - Stage Patterns Defines a framework activity eg. Communication - Task Patterns - Defines a work task eg. Requirements gathering Problem - The problem to be solved Solution - The implementation of the pattern (How to transform the pre-requisite into a pattern) Resulting context - The resulting conditions after successful implementations of pattern Related Patterns - List of all associated patterns eg. Requirements gathering is an associated pattern to communication Known Uses/Examples - When to apply a pattern eg. communication must be throughout the development 1.3.0 Points to Ponder (?!) or Points to Remember Process templates are effective mechanisms for describing any software process. They enables an organization ( a s/w engineering) to develop a hierarchical process description of their current process. Once a process template is developed, it can be reused for similar project carried out by the organization. What are the process assessment standards that are available for software engineering? The renowned approaches are listed here: SCAMPI - Standard CMMI Assessment Method for Process Improvement SEI CMM CBA IPI CMM Based Assessment for Internal Process Improvement

 ISO 9001:2000 for Standards - Higher quality products & customer satisfaction 1.4 Personal and Team Process Models According to Watts Humphrey the best S/w process is one that is close to the its developers. Every S/w engineer would create a process that best fits his needs as well as the needs of the organization they belong to. Likewise, a team creates their own S/w process to meet the narrower needs of the individuals and to meet the broader needs of the org. Such processes are called personal software processes. What is personal software process ? Every developer uses some process that is close to his hearts. The process may be Haphazard, Ad hoc, may change on a daily basis, ineffective, efficient or successful, but a process exists and they empowers the practitioners to control the quality. What is team software process ? A software process developed by self directed teams which strives to accelerate software process by making CMM L5 behavior as normal and expected. The team understands its goals, defines their own roles, create and identify a team process by tracking and reporting progress. They also set local standards, assess risks, and reacts to risks very quickly. 1.5 Software Process Models Every software engineering organization should describe an unique set of framework activities required to develop a quality software. The Framework activities include Actions, task sets and work products. A process model has to be selected for categorizing & controlling various activities. Framework activities are going to remain in all process models with only the emphasis & workflow is different. 1.5.0 Prescriptive Process Models Prescribe a set of activities, models, actions, tasks, work products and work flow. The most fabulous Prescriptive model being the Waterfall Model. 1.5.0.1 Waterfall Model A model which is known very well as Linear Sequential Model or Phased life cycle model or Classic Life cycle Model, emphasizes a systematic and sequential approach.

Each phase is explicitly completed with specific baselines or milestone and all preceding phases are completed before the moving to the next one. Waterfall model primarily emphasizes the following assumptions: 1. All uncertainties & requirements are defined at the beginning of the project. 2. Output of one software engineering phase acts as an the input (baselines) of the next phase. 3. Every phase ends with the verification and validation of its baselines.

Diagram 1.0 - Waterfall model Phases of Waterfall Model 1. 2. 3. 4. 5. Communication - Requirements gathering Planning Requirements analysis, estimation Modeling Architectural Design Construction Coding and testing Deployment - Operation and maintenance

Problems of Waterfall Model or Situations where Waterfall is inappropriate Real projects rarely follow sequential model, without much iteration & changes can be confusing The original model (Winston Royce) has feedback loops but not widely used It is often difficult for the clients to state requirements explicitly in all cases Difficult to accommodate the natural uncertainty that exists in the beginning of every project Customer must have patience, since a working version of the whole product will be available to him only at the end A major blunder, undetected until the end will become disastrous

 Blocking state In waterfall model, some members of the development team will wait for the others to finish their portion of the work. This will make the time waiting more than Productive time Lots of documents need to be generated and for this a substantial portion of the work must be dedicated Lot of upfront activities such as communication, planning & modeling consumes more time in an era where changes are continuous 1.5.1 Evolutionary Models Why Evolutionary models ? Software, like any other product, evolves over a period of time and Business and Product requirements often change as development proceeds, making a straight line path to an end product unrealistic. In such situations comprehensive product may be impossible but a limited version to meet the business pressure can be developed quickly. Moreover, the evolutionary software is iterative in nature and enables S/w engineers to create increasingly more complex versions of the software The following are some of the distinguished evolutionary models. 1.5.1.0 Prototyping Often, a customer defines a set of general objectives for software but does not identify detailed input, processing, or output requirements. In such situations and in many other situations, a prototyping paradigm may offer the best approach. The prototyping paradigm begins with requirements gathering. Developer and customer meet and define the overall objectives for the software, identify whatever requirements are known, and outline areas where further definition is mandatory. A "quick design" then occurs. The quick design focuses on a representation of those aspects of the software that will be visible to the customer/user. This quick design is converted into a prototype. The created prototype is delivered to the customer and evaluated by him/her for refining the requirements. Iteration occurs as the prototype is tunes or refined to satisfy the customer. Ideally, the prototype serves as a mechanism for identifying software requirements. The prototyping process has the following assumptions. A right way to star the process if requirements are fuzzy A throwaway prototype is created based on the known requirements Every iteration should be delivered to the client for evaluation

 Iterations need not encompass all features of the expected product but includes major features a customer desires (may be simple document or a working program) After the evaluation, the prototype is refined to satisfy the customer In most of the projects, the first system is almost unusable Developer needs to resist pressure to extend a rough prototype into a product

Diagram 1.1 Prototyping Model The drawbacks of Prototyping process The customer sees what appears to be a working version of the Software, unaware that in the rush to make it work, quality and long-term maintainability may not be considered (Lack of Process Visibility) The developer makes lot of implementation compromises to get a prototype working quickly Inappropriate OS, poor programming language, inefficient algorithm might be selected because they are known & available. After some time the developer becomes comfortable with this choices and forgets why they where inappropriate ( Systems are often poorly structured) 1.5.1.1 The Incremental Model A compelling need to provide a limited set of software functionality quickly to the users with refined and expanded functionality in later releases has paved a way to incremental models. The incremental model combines elements of the linear sequential model (applied repetitively) with the iterative philosophy of prototyping. When an incremental model is used, the first increment is often a core product.

That is, basic requirements are addressed, but many supplementary features (some known, others unknown) remain undelivered. The core product is used by the customer (or undergoes detailed review). As a result of use and/or evaluation, a plan is developed for the next increment. The plan addresses the modification of the core product to better meet the needs of the customer and the delivery of additional features and functionality. This process is repeated following the delivery of each increment, until the complete product is produced.

Diagram - 1.2 The Incremental model The incremental model has the following assumptions: The process is repeated following the delivery of each increment until the complete product is produced Focus is on the delivery of each product and not model The Benefits of Incremental Model Incremental development is particularly useful when staffing is unavailable for the complete implementation by the business deadline that has been established for a project. Early increments can be implemented with fewer people. If the core product is well received, then additional staff (if required) can be added to implement the next increment provided that increments can be planned to manage technical risks.

1.5.1.2 Spiral Model The spiral model, is an evolutionary software process model that couples the iterative nature of prototyping with the controlled and systematic aspects of the linear sequential model. It provides a method to develop and release incremental versions of the software. The early iterations of the incremental release might be a paper model or prototype. During later iterations, increasingly more complete versions of the engineered system are produced. A spiral model is divided into a number of framework activities, also called task regions. Typically, there are between three and six task regions. The following figure depicts a spiral model that contains six task regions:

Diagram 1.3 - Spiral model The six task regions Customer communicationtasks required to establish effective communication between developer and customer. Planningtasks required to define resources, timelines, and other project related information. Risk analysistasks required to assess both technical and management risks. Engineeringtasks required to build one or more representations of the application. Construction and releasetasks required to construct, test, install, and provide user support (e.g., documentation and training). Customer evaluationtasks required to obtain customer feedback based on evaluation of the software representations created during the engineering stage and implemented during the installation stage.

As this evolutionary process begins, the software engineering team moves around the spiral in a clockwise direction, beginning at the center. The first circuit around the spiral might result in the development of a product specification; subsequent phases around the spiral might be used to develop a prototype and then progressively more sophisticated versions of the software. Spiral Model Points to Ponder Unlike classical process models that end when software is delivered, the spiral model can be adapted to apply throughout the life of the computer software. The software product will evolve through a number of iterations around the spiral, remains operative until the software is retired. Whenever a change is initiated, the process starts at the appropriate entry point. Spiral Model When to use and when not to use The spiral model is a realistic approach to the development of large-scale systems and software. It maintains the systematic stepwise approach suggested by the classic life cycle but incorporates it into an iterative framework that more realistically reflects the real world. Requires a considerable experience and expertise to reduce the risks and if any major risk left uncovered will undoubtedly cause huge damages.

1.5.1.3 The Concurrent Development Model The concurrent development model is also called as concurrent engineering. The concurrent process model can be represented schematically as a series of major technical activities, tasks, and their associated states. Early in a project customer communication activity has completed its first iteration and exists in the awaiting changes state. The analysis activity which existed in the none state while initial customer communication was completed now makes a transition into the under development state. If, however, the customer again wants to make some changes in requirements the analysis activity moves from the under development state into the awaiting changes state. The concurrent process model defines a series of events that will trigger transitions from state to state for each of the software engineering activities. In reality, the concurrent process model is applicable to all types of software development and suits well to client/server applications and provides an accurate picture of the current state of a project. Rather than confining software engineering activities to a sequence of events, it defines a network of activities.

1.5.1.4 Component Based Development Object-oriented technologies (I hope you know something about it!) provide the technical framework for a component-based process model for software engineering. The objectoriented paradigm emphasizes the creation of classes that encapsulate both data and the functions or methods used to manipulate the data. If properly designed and implemented, object-oriented classes are reusable across different applications and computer-based system architectures. Key points about Component based development The component-based development (CBD) model incorporates many of the characteristics of the spiral model. It is evolutionary in nature, demanding an iterative approach to the creation of software. However, the component-based development model composes applications from prepackaged software components (called classes). Process The engineering activity begins with the identification of candidate classes. The required data and methods are encapsulated or packaged into candidate classes. Classes created during past projects are stored in a class library or repository. Once the candidate classes are identified, the class library is searched to find whether these classes already exists. If the class already exist in the repository, they are extracted and used and if they dont they are engineered. The Benefits The component-based development model leads to software reuse, and reusability provides software engineers with a number of measurable benefits. According to the study conducted by QSM Associates, Inc., component based process assembly leads to a 70 percent reduction in development cycle time; an 84 percent reduction in project cost and a high productivity rate index of 26.2 The big question Though the component based software engineering process reduces the effort and increases productivity, people argue that it is due to the robustness of the classes in repository and not due to component usage.

Diagram 1.4 The component based software development 1.5.2 Agile Methods The existing methodologies are imposing lot of rules to follow and they make the developers write lot of documents. The focus and effort is more on the analysis and design and very little on coding and integration. Due this nature, these methodologies are called heavyweight methodologies. The need for a new and agile methodology evolved due to the resistance to change offered by such existing methodologies. A simple method with less rules and little documentation may be the ideal solution to the above scenario. These methodologies are called agile or lightweight methodologies. What are agile methods? A lightweight and simple method that accommodates changes at any point of the development process. A people based approach to software development and not plan based development. Developed by Agile Alliances and comprises of a number of process models including XP, Scrum and Open source software development. 1.5.2.1 XP Extreme Programming Kent Back developed a model called XP and is the most celebrated agile method. The XP model has the following characteristics. incremental - small software releases with rapid cycles cooperative - customers and developers are working together

straightforward the method modify and well documented Adaptive - able to make changes

itself

is

easy

to

learn

and

to

XP Process 1. Customers writes stories 2. Programmers estimate effort of implementing customer stories and customer decides about scope and timing of releases 3. Small releases that allow rapid feedbacks 4. A new release every 2-3 months 5. Emphasis is on simplest design 6. Development is test driven and all unit tests need to run successfully. 7. If a test fails, the pair of developer and customer has to repair it. 8. If repair takes more productive time, it has to be discarded or thrown away to develop a new unit. XP Points to Ponder XP allows Collective Ownership of Code, where any one can change the code and all are responsible for the performance. XP emphasizes continuous code integration. XP allows personal and team software processes.