AgileNotes.pdf

Unit – 1 Software Process and Agile Development Introduction to Software Engineering, Software Process, Perspective and Specialized Process Models – Introduction to Agility – Agile Process – Extreme Programming – XP process Software...

Unit – 1 Software Process and Agile Development Introduction to Software Engineering, Software Process, Perspective and Specialized Process Models – Introduction to Agility – Agile Process – Extreme Programming – XP process Software Engineering - Introduction 1.1. INTRODUCTION "Software engineering is a discipline in which theories, methods and tools are applied to develop professional software product” In software engineering the systematic and organized approach is adopted. Based on the nature of the problem and development constraints various tools and techniques are applied in order to develop quality software. The definition of software engineering is based on two terms: Discipline: For finding the solution to the problem an Engineer applies appropriate theories, methods and tools. While finding the solutions, Engineers must think of the organizational and financial constraints. Within these constraints only, he/she has to find the solution. Product: The software product gets developed after following systematic theories, methods and tools along with the appropriate management activities. 1.2. Defining Software Software is nothing but a collection of computer programs and related documents that are intended to provide desired features, functionalities and better performance. Software products may be: Generic - That means developed to be sold to a range of different customers. Custom - That means developed for a single customer according to their specification. 1.2.1 Software Characteristics Software development is a logical activity and therefore it is important to understand basic characteristics of software. Some important characteristics of software are:  Software is engineered, not manufactured Software development and hardware development are two different activities. A good design is a backbone for both the activities. Quality problems that occur in hardware manufacturing phase cannot be removed easily. On the other hand, during software development process such problems can be rectified. In both the activities, developers are responsible for producing qualitative product.  Software does not ware out In early stage of hardware development process the failure rate is very high because of manufacturing defects. But after correcting such defects the failure rate gets reduced. The failure rate remains constant for some period of time and again it starts increasing because of environmental maladies (extreme temperature, dusts, and vibrations). On the other hand software does not get affected from such environmental maladies. Hence ideally it should have an "idealized curve". But due to some undiscovered errors the failure rate is high and drops down as soon as the errors get corrected. Hence in failure rating of software the "actual curve" is as shown below: Failure Curve for Hardware and Software During the life of software if any change is made, some defects may get introduced. This causes failure rate to be high. Before the curve can return to original steady state another change is requested and again the failure rate becomes high. Thus the failure curve looks like a spike. Thus frequent changes in software cause it to deteriorate. Another issue with software is that there are no spare parts for software. If hardware component wears out it can be replaced by another component but it is not possible in case of software. Therefore software maintenance is more difficult than the hardware maintenance.  Most software is custom built rather than being assembled from components While developing any hardware product firstly the circuit design with desired functioning properties is created. Then required hardware components such as ICs, capacitors and registers are assembled according to the design, but this is not done while developing software product. Most of the software is custom built. However, now the software development approach is getting changed and we look for reusability of software components. It is practiced to reuse algorithms and data structures. Today software industry is trying to make library of reusable components. For example: in today's software, GUI is built using the reusable components such as message windows, pull down menus and many more such components. The approach is getting developed to use in-built components in the software. This stream of software is popularly known as component engineering. 1.2.2 Categories of Software Software can be applied in a situation for which a predefined set of procedural steps (algorithm) exists. Based on a complex growth of software it can be classified into following categories. System software It is collection of programs written to service other programs. Typical programs in this category are compiler, editors, and assemblers. The purpose of the system software is to establish a communication with the hardware. Application software It consists of standalone programs that are developed for specific business need. This software may be supported by database systems. Engineering/scientific software This software category has a wide range of programs from astronomy to volcanology, from automative stress analysis to space shuttle orbital dynamics and from molecular biology to automated manufacturing. This software is based on complex numeric computations. Embedded software This category consists of program that can reside within a product or system. Such software can be used to implement and control features and functions for the end-user and for the system itself. Web applications Web application software consists of various web pages that can be retrieved by a browser. The web pages can be developed using programming languages like JAVA, PERL, CGI, HTML, DHTML. Artificial intelligence software This kind of software is based on knowledge based expert systems. Typically, this software is useful in robotics, expert systems, image and voice recognition, artificial neural networks, theorem proving and game playing. 1.3 Goals and Objectives of Software. While developing software following are common objectives. Satisfy user’s requirements Many programmers simply don't do what the end user wants because they do not understand user requirements. Hence it becomes necessary to understand the demand of end user and accordingly software should be developed. High reliability Mistakes or bugs in a program can be expensive in terms of human lives, money, and customer relation. For instance, Microsoft has faced many problems because earlier release of windows has many problems. Thus software should be delivered only if high reliability is achieved. Low maintenance costs Maintenance of software is an activity that can be done only after delivering the software to the customer. Any small change in software should not cause restructuring of whole software. This indicates that the design of software has poor quality. Delivery on time It is very difficult to predict the exact time on which the software can be completed. But a systematic development of software can lead to meet the given deadline. Low production costs The software product should be cost effective. High performance The high performance software are expected to achieve optimization in speed and memory usage. Ease of reuse Use same software in different systems and software. Environments reduce development costs and also improve the reliability. Hence reusability of developed software is an important property. 1.4 Challenges in Software Engineering The key challenges facing software engineering are: Coping with legacy systems Old, valuable systems must be maintained and updated. Hardware is evolved faster than software. If original developer have moved on managing, maintaining or integrating of software becomes a critical issue. Heterogeneity challenge Sometimes systems are distributed and include a mix of hardware and software. This implies that software systems must cleanly integrate with other different software systems, built by different organizations and teams using different hardware and software platforms. Delivery time’s challenge There is increasing pressure for faster delivery of software. As the complexity of systems that we develop increases, this challenge becomes harder. As software is an integral part of computer based systems, it is essential to apply software engineering principles and practices while developing software. Hence the main objective of software engineering is to adopt systematic, disciplined approach while building high quality software. 1.5 Software Myths There are some misbelieves in the software industry about the software and process of building software. For any software developer it is a must to know such beliefs and reality about them. Here are some typical myths – Myth: Using a collection of standards and procedures one can build software. (Management Myth) Reality: Even though we have all standards and procedures with us for helping the developer to build software, it is not possible for software professionals to build desired product. This is because - the collection which we have should be complete, it should reflect modern techniques and more importantly it should be adaptable. It should also help the software professional to bring quality in the product. Myth: Add more people to meet deadline of the project. (Management Myth) Reality: Adding more people in order to catch the schedule will cause the reverse effect on the software project i.e. software project will get delayed. Because, we have to spend more time on educating people or informing them about the project. Myth: If a project is outsourced to a third party then all the worries of software building are over. (Management Myth) Reality: When a company needs to outsource the project then it simply indicates that the company does not know how to manage the projects. Sometimes, the outsourced projects require proper support for development. Myth: Even if the software requirements are changing continuously it is possible to accommodate these changes in the software. (Customer Myth) Reality: It is true that software is a flexible entity but if continuous changes in the requirements have to be incorporated then there are chances of introducing more and more errors in the software. Similarly, the additional resources and more design modifications may be demanded by the software. Myth: We can start writing the program by using general problem statements only. Later on using problem description we can add up the required functionalities in the program. (Customer Myth) Reality: It is not possible each time to have comprehensive problem statement. We have to start with general problem statements; however by proper communication with customer the software professionals can gather useful information. The most important thing is that the problem statement should be unambiguous to begin with. Myth: Once the program is running then it’s over! (Practitioner's Myth) Reality: Even though we obtain that the program is running major part of work is after delivering it to customer. Myth: Working program is the only work product for the software project. (Practitioner's Myth) Reality: The working program/software is the major component of any software project but along with it there are many other elements that should be present in the software project such as documentation of software, guideline for software support. Myth: There is no need of documenting the software project; it unnecessarily slows down the development process. (Practitioner's Myth) Reality: Documenting the software project helps in establishing ease in use of software. It helps in creating better quality. Hence documentation is not wastage of time but it is a must for any software project. 1.6 Software Crisis The software crisis means the decisive time or turning point that software developer’s encounter during software development. Hence software crisis represent various problems that are faced by the software developers during software development process. To understand software crisis consider following problem that is often faced by software industry.  Software cost: A software crisis Software cost is getting increased tremendously day-by-day. The software purchase expenses are higher than the hardware purchase. This is becoming worrying trend over the years. Following graph shows the ratio of h/w and s/w cost vs. years This graph shows that cost of software is increasing rapidly than the hardware cost. Following are the symptoms of present software crisis - 1) Day-by-day, software purchase cost is getting more than the hardware purchase cost. Hence major part of budget of any software industry is on software purchase. 2) Software products are difficult to alter, maintain, enhance, debug or modify. 3) Software resources are not being used optimally. 4) User requirements are often evolving and cannot be satisfied fully. 5) Software product not being reliable. 6) Many time software products get crashed on occurrence of specific condition. 7) Delivery of software product within specified budget and on scheduled time. Various factors that have contributed to make software crisis Following are some factors that bring the software crisis - 1) Increasing size or volume of software. 2) Lowered productivity or quality improvement. 3) Lack of skilled staff. 4) Inadequate software training. 5) Growing demand for more software. Solutions to present software crisis - The most effective solutions to present software crisis can be 1) Use and spread of software engineering practices among software engineers and 2) Further enhancement in software engineering disciplines. 1.7 Difference between Software Product and Program Sl. Program Software product No Software product is developed by multiple Programs are developed by individual user 1. users and it is used by large number of and it is used for personal use. people or customers.  Software product consists of multiple Programs are small in size and possessing program codes, related documents such as 2. limited functionality. SRS, design documents user manuals, test cases and so on. Generally only one person uses the Good graphical user interface is most 3. program, hence there is a lack of user required by any software product. interface. Software product is developed by software Program is generally developed by engineers who are large in number and work 4 programmers in a team. Therefore systematic approach of developing software product must be applied. Example: Example: Program of Sorting of n elements A word processing software Software Process 1.8 Layered Technology Software engineering is a layered technology. Any software can be developed using these layered approaches. Various layers on which the technology is based are quality focus layer, process layer, methods layer, tools layer. A disciplined quality management is a backbone of software engineering technology. Process layer is a foundation of software engineering. Basically, process defines the framework for timely delivery of software. In method layer the actual method of implementation is carried out with the help of requirement analysis, designing, coding using desired programming constructs and testing. Software tools are used to bring automation in software development process. Thus software engineering is a combination of process, methods, and tools for development of quality software. 1.9 Software Process Software process can be defined as the structured set of activities that are required to develop the software system. The fundamental activities are:  Specification   Design and implementation  Validation  Evolution A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective. 1. 9.1 Common Process Framework The process framework is required for representing the common process activities. As shown in the figure below, the software process is characterized by process framework activities, task sets and umbrella activities. Process framework activities  Communication  By communicating customer requirement gathering is done.  Planning - Establishes engineering work plan, describes technical risks, lists resource requirements, work products produced and defines work schedule.  Modeling - The software model is prepared by :  Analysis of requirements  Design  Construction - The software design is mapped into a code by :  Code generation  Testing  Deployment - The software delivered for customer evaluation and feedback is obtained. Task sets - The task set defines the actual work done in order to achieve the software objective. The task set is used to adopt the framework activities and project team requirements using:  Collection of software engineering work tasks  Project milestones  Software quality assurance points Umbrella activities - The umbrella activities occur throughout the process. They focus on project management, tracking and control. The umbrella activities are  Software project tracking and control - This is an activity in which software team can assess progress and take corrective action to maintain schedule.  Risk management - The risks that may affect project outcomes or quality can be analyzed.  Software quality assurance - These are activities required to maintain software quality.  Formal technical reviews - It is required to assess engineering work products to uncover and remove errors before they propagate to next activity. 1.9.2 Capability maturity Model(CMM) The software engineering Institute (SEI) has developed a comprehensive process Meta – model emphasizing process maturity. It is predicted on a set of system and software capabilities that should be present when organizations reach different levels of process capability and maturity. The capability maturity model (CMM) is used I accessing how well an organization‘s processes allow to complet and manage new software projects. Various process maturity levels are: 1. Initial- Few processes are defined, and success depends on individual effort.  2. Repeatable-Basic process management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar applications. 3. Defined -The software process for both management and engineering activities is documented, standardized, and integrated into a standard software process for the organization. All projects use an approved, tailored version of the organization’s standard software process for developing an maintaining software. 4. Managed- Both the software process and products are quantitatively understood and controlled. 5. Optimizing- Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies. Thus CMM is used for improving the software Project. Perspective and Specialized Process Model 1. 10 Perspective and Specialized Process Models  Definition:The process model can be defined as the abstract representation of process. The appropriate process model can be chosen based on abstract representation of process.  The software process model is also known as software development life cycle (SDLC) model or software paradigm.  These models are called perspective process models because they are following some rules for correct usage.  Various perspective models are as follows 1.10.1 Waterfall Model The software development starts with requirements gathering phase. Then progresses through analysis, design, coding, testing and maintenance. Following figure illustrates waterfall model. Waterfall Model In REQUIREMENT GATHERING AND ANALYSIS phase the basic requirements of the system must be understood by software engineer, who is also called Analyst. The information domain, function, behavioral requirements of the system are understood. All these requirements are then well documented and discussed further with the customer, for reviewing. The DESIGN is an intermediate step between requirements analysis and coding. Design focuses on program attributes such as -  Data structure  Software architecture  Interface representation  Algorithmic details. The requirements are translated in some easy to represent form using which coding can be done effectively and efficiently. The design needs to be documented for further use. CODING is a step in which design is translated into machine-readable form. If design is done in sufficient detail then coding can be done effectively. Programs are created in this phase. TESTING begins when coding is done. While performing testing the major focus is on logical internals of the software. The testing ensures execution of all the paths, functional behaviors. The purpose of testing is to uncover errors, fix the bugs and meet the customer requirements. MAINTENANCE is the longest life cycle phase. When the system is installed and put in practical use then error may get introduced, correcting such errors and putting it in use is the major purpose of maintenance activity. Similarly, enhancing system’s services as new requirements are discovered is again maintenance of the system. This model is widely used model, although it has many drawbacks. Benefits of waterfall model The waterfall model is simple to implement. For implementation of small systems waterfall model is useful. Drawbacks of waterfall model There are some problems that are encountered if we apply the waterfall model and those are : 1) It is difficult to follow the sequential flow in software development process. If some changes are made at some phases then it may cause some confusion. 2) The requirement analysis is done initially and sometimes it is not possible to state all the requirements explicitly in the beginning. This causes difficulty in the project. 3) The customer can see the working model of the project only at the end. After reviewing of the working model; if the customer gets dissatisfied then it causes serious problems. 4) Linear nature of waterfall model induces blocking states, because certain tasks may be dependent on some previous tasks. Hence it is necessary to accomplish all the dependent tasks first. It may cause long waiting time. 1. 10.2 Incremental Process Model In this model, the initial model with limited functionality is created for user’s understanding about the software product and then this model is refined and expanded in later releases. 1.10.2.1 Incremental Model The incremental model has same phases that are in waterfall model. But it is iterative in nature. The incremental model has following phases. 1) Analysis 2) Design 3) Code 4) Test The incremental model delivers series of releases to the customer. These releases are called increments. More and more functionality is associated with each increment. Incremental Model  The incremental model delivers series of releases to the customer. These releases are called increments. More and more functionality is associated with each increment.  The first increment is called core product. In this release the basic requirements are implemented and then in subsequent increments new requirements are added.  The word processing software package can be considered as an example of incremental model. In the first increment only the document processing facilities are available. In the second increment, more sophisticated document producing and processing facilities, file management functionalities are given. In the next increment spelling and grammar checking facilities can be given. Thus in incremental model progressive functionalities are obtained with each release. When to choose it? 1) When requirements are reasonably well-defined. 2) When overall scope of the development effort suggests a purely linear effort. 3) When limited set of software functionality needed quickly. Merits of incremental model 1) The incremental model can be adopted when there are less number of people involved in the project. 2) Technical risks can be managed with each increment. 3) For a very small time span, at least core product can be delivered to the customer. 1.10.2.2 RAD Model  The RAD Model is a type of incremental process model in which there is EXTREMELY SHORT DEVELOPMENT CYCLE.  When the requirements are fully understood and the COMPONENT BASED CONSTRUCTION approach is adopted then the RAD model is used.   Using the RAD model the fully functional system can be developed WITHIN 60 TO 90 DAYS.  Various phases in RAD are Requirements Gathering, Analysis and Planning, Design, Build or Construction and finally Deployment.  Multiple teams work on developing the software system using RAD model parallel.  In the REQUIREMENTS GATHERING phase the developers communicate with the users of the system and understand the business process and requirements of the software system.  During ANALYSIS AND PLANNING phase, the analysis on the gathered requirements is made and a planning for various software development activities is done.  During the design phase various models are created. Those models are Business model, data model and process model.  The build is an activity in which using the existing software components and automatic code generation tool the implementation code is created for the software system. This code is well tested by its team. The functionalities developed by all the teams are integrated to form a whole.  Finally the deployment of all the software components (created by various teams working on the project) is carried out.. Drawbacks of rapid application development  It requires multiple teams or large number of people to work on the scalable projects.  This model requires heavily committed developer and customers. If commitment is lacking then RAD projects will fail.  The projects using RAD model requires heavy resources.  If there is no appropriate modularization then RAD projects fail. Performance can be problem to such projects.  The projects using RAD model find it difficult to adopt new technologies. Applications of RAD Model The RAD model is suitable for information system applications, business applications and the for systems that can be modularized because of following reasons - This model is similar to waterfall model but it uses very short development cycle. It uses component-based construction and emphasizes reuse and code generation. This model uses multiple teams on scalable projects. The RAD model is suitable for the projects where technical risks are not high. The RAD model requires heavy resources. 1.10.3 Evolutionary Process model 1.10.3.1Spiral Model  This model possess the iterative nature of prototyping model and controlled and systematic approaches of the linear sequential model.  This model gives efficient development of incremental versions of software. In this model, the software is developed in series of increments.  The spiral model is divided into a number of framework activities. These framework activities are denoted by task regions.  Usually there are six tasks regions. The spiral model is as shown in the figure below  Spiral model is realistic approach to development of large-scale systems and software. Because customer and developer better understand the problem statement at each evolutionary level. Also risks can be identified or rectified at each such level. In the initial pass, product specification is built and in subsequent passes around the spiral the prototype gets developed and then more improved versions of software gets developed. During planning phase, the cost and schedule of software can be planned and adjusted based on feedback obtained from customer evaluation. In spiral model, project entry point axis is defined. This axis represents starting point for different types of projects. For instance, concept development project will start at core of spiral and will continue along the spiral path. If the concept has to be developed into actual project then at entry point 2 the product development process starts. Hence entry point 2 is called product development project entry point. The development of the project can be carried out in iterations. The task regions can be described as : 1) Customer communication - In this region, it is suggested to establish customer communication. 2) Planning - All planning activities are carried out in order to define resources time line and other project related activities. 3) Risk analysis - The tasks required to calculate technical and management risks are carried out. 4) Engineering - In this task region, tasks required to build one or more representations of applications are carried out. 5) Construct and release - All the necessary tasks required to construct, test, install the application are conducted. Some tasks that are required to provide user support are also carried out in this task region. 6) Customer evaluation - Customer's feedback is obtained and based on customer evaluation required tasks are performed and implemented at installation stage. In each region, numbers of work tasks are carried out depending upon the characteristics of project. For a small project relatively small numbers of work tasks are adopted but for a complex, project large number of work tasks can be carried out. In spiral model, the software engineering team moves around the spiral in a clockwise direction beginning at the core. Advantages of spiral model  Requirement changes can be made at every stage.  Risks can be identified and rectified before they get problematic. Drawbacks of spiral mode!  It is based on customer communication. If the communication is not proper then the software product that gets developed will not be up to the mark.  It demands considerable risk assessment. If the risk assessment is done properly then only the successful product can be obtained. When to choose it? 1) When the prototypes for the software functionality are needed. 2) When requirements are not very clearly defined or complex. 3) When the large or high budget projects need to be developed. 4) When the risk assessment is very critical and essential 5) When project is not expected within a specific limited time span. 1.10.3.2 Prototyping model  Gather requirements  Developer & customer define overall objectives, identify areas needing more investigation – risky requirements  Quick design focusing on what will be visible to user – input & output formats  Use existing program fragments, program generators to throw together working version  Prototype evaluated and requirements refined  Process iterated until customer & developer satisfied  Then throw away prototype and rebuild system to high quality   Alternatively can have evolutionary prototyping – start with well understood requirements. Prototyping Drawbacks  Customer may want to hang onto first version, may want a few fixes rather than rebuild. First version will have compromises  Developer may make implementation compromises to get prototype working quickly. Later on developer may become comfortable with compromises and forget why they are inappropriate Comparison between Spiral model and Prototyping model Spiral model Prototyping model The development team with less domain The development team has adequate domain knowledge can be accommodated due to knowledge. Similarly they can adopt the new iterative nature of this model. The change in technologies if product demands. technology in the later phase cannot be tolerated. All the end-users need not be involved in all All the end-users are involved in all phases of the phases of development. development. Funding are not stable for the projects that can Funding are stable for these type of projects. be developed using spiral model. The requirements that are gathered and Some requirements are gathered initially, but analyzed are high reliability requirements. there may be change in requirements when the working prototype is shown to the customer. 1.10.3.3 Concurrent Development Model  Allow a software team to represent iterative and concurrent elements of any of the process models. For example, the modeling activity defined for the spiral model is accomplished by invoking one or more of the following actions: prototyping, analysis and design.   The Figure shows modeling may be in any one of the states at any given time. For example, communication activity has completed its first iteration and in the awaiting changes state. The modeling activity was in inactive state, now makes a transition into the under development state. If customer indicates changes in requirements, the modeling activity moves from the under development state into the awaiting changes state.  Concurrent modeling is applicable to all types of software development and provides an accurate picture of the current state of a project. Rather than confining software engineering activities, actions and tasks to a sequence of events, it defines a process network. Each activity, action or task on the network exists simultaneously with other activities, actions or tasks. Events generated at one point trigger transitions among the states. 1.11 Specialized Process Models The specialized models are used when only collecting of specialized technique or methods are expected for developing the specific software. Various types of specialized models are 1. Component based development 2. Formal methods model. 3. Aspect oriented software development. 1.11.1 Component Based Development Commercial off-the-shelf (COTS) Software components, developed by vendors who offer them as products, can be used when Software is to be built. These components provide targeted functionality with well-defined interfaces that enable the component to be integrated into the Software. The component-based development model incorporates many of the characteristics of the spiral model. The component-based development model incorporates the following steps:  Available component-based products are researched and evaluated for the application domain in question.  Component integration issues are considered.  Software architecture is designed to accommodate the components.  Components are integrated into the architecture.  Comprehensive testing is conducted to ensure proper functionality. The component-based development model leads to Software reuse, and reusability provides Software engineers with a number of measurable benefits. 1.11.2 The Formal Methods Model The Formal Methods Model encompasses a set of activities that leads to formal mathematical specifications of Software. Formal methods enable a Software engineer to specify, develop, and verify a computer-based system by applying a rigorous, mathematical notation. A variation of this approach, called clean-room Software engineering is currently applied by some software development organizations. Although not a mainstream approach, the formal methods model offers the promise of defect- free Software. Yet, concern about its applicability in a business environment has been voiced:  The development of formal models is currently quite time-consuming and expensive.  B/C few software developers have the necessary background to apply formal methods, extensive training is required.  It is difficult to use the methods as a communication mechanism for technically unsophisticated customers. 1.11.3 Aspect-Oriented Software Development Regardless of the software process that is chosen, the builders of complex software invariably implement a set of localized features, functions, and information content. These localized software characteristics are modeled as components and then constructed within the context of system architecture. As modern computer-based systems become more sophisticated and complex, certain concerns, customer required properties or areas of technical interest, span the entire architecture. Some concerns are high-level properties of a system; others affect functions or are systemic. When concerns cut across multiple system functions, features, and information they are often referred to as crosscutting concerns.  Aspectual requirements define those crosscutting concerns that have impact across the software architecture. Aspects are mechanisms beyond subroutines and inheritance for localizing the expression of a crosscutting concerns. Aspect-oriented software development (AOSD), often referred to as aspect-oriented programming (AOP), is a relatively new software engineering paradigm that provides a process and methodological approach for defining, specifying, designing, and constructing aspects. 1.12 Introduction to Agility The word ‘agile’ means −  Able to move your body quickly and easily.  Able to think quickly and clearly. In business, ‘agile’ is used for describing ways of planning and doing work wherein it is understood that making changes as needed is an important part of the job. Business‘agililty’ means that a company is always in a position to take account of the market changes. Ref: Cambridge Dictionaries online. In software development, the term ‘agile’ is adapted to mean ‘the ability to respond to changes − changes from Requirements, Technology and People.’ 1.12.1 Agile Manifesto A team of software developers published the Agile Manifesto in 2001, highlighting the importance of the development team, accommodating changing requirements and customer involvement. The Agile Manifesto states that − We are uncovering better ways of developing software by doing it and helping others do it. Through this work, we have come to value −  Individuals and interactions over processes and tools.  Working software over comprehensive documentation.  Customer collaboration over contract negotiation.  Responding to change over following a plan. That is, while there is value in the items on the right, we value the items on the left more. Agile process  In 1980’s the heavy weight, plan based software development development approach was used to develop any software product.  In this approach too many things are done which were not directly related to software product being produced.  This approach is rigid, that means if requirements get changed, then rework was essential. Hence new methods were proposed in 1990;s which are known as agile process.  The agile processes are the light-weight methods are people –based rather than plan based methods.  The agile process forces the development team to focus on software itself rather than design and documentation.  The agile process believes in iterative method.  The aim of agile process is to deliver the working model of software quickly to the customer. For Eg: Extreme programming is the best known of agile process Conventional software development methodology  As the software project makes the progress ,the cost of the changes increases non linearly.  It is easy to accommodate changes during the requirement gathering stage. at this stage to accommodate the changes-usage scenarios are modified, list of functions can be extended, or written specification be edited.  As the progresses and if the customer suggest the changes during the testing phase of the software development life cycle then to accommodate these changes the architectural design needs to be modified and ultimately these changes will affect other phases of software development cycle. These changes are actually costly to execute. Agile Methodology  The agile method proponents claim that if the software development is carried out using the agile approach then it will allow the software team to accommodate changes late in a software project without dramatic cost and time impact.  In other words, if the incremental delivery is combined with agile practices such as continuous unit testing and pair programming then the cost of changes can be controlled.  The following graph represents how the software development approach has a strong influence on the development cost due to changes suggested. 1.12.2 The Twelve Agile Manifesto Principles The Twelve Principles are the guiding principles for the methodologies that are included under the title “The Agile Movement.” They describe a culture in which change is welcome, and the customer is the focus of the work. They also demonstrate the movement’s intent as described by Alistair Cockburn, one of the signatories to the Agile Manifesto, which is to bring development into alignment with business needs. The twelve principles of agile development include:  Customer satisfaction through early and continuous software delivery – Customers are happier when they receive working software at regular intervals, rather than waiting extended periods of time between releases.  Accommodate changing requirements throughout the development process – The ability to avoid delays when a requirement or feature request changes.  Frequent delivery of working software – Scrum accommodates this principle since the team operates in software sprints or iterations that ensure regular delivery of working software.  Collaboration between the business stakeholders and developers throughout the project – Better decisions are made when the business and technical team are aligned.  Support, trust, and motivate the people involved – Motivated teams are more likely to deliver their best work than unhappy teams.  Enable face-to-face interactions – Communication is more successful when development teams are co-located.  Working software is the primary measure of progress – Delivering functional software to the customer is the ultimate factor that measures progress.  Agile processes to support a consistent development pace – Teams establish a repeatable and maintainable speed at which they can deliver working software, and they repeat it with each release.  Attention to technical detail and design enhances agility – The right skills and good design ensures the team can maintain the pace, constantly improve the product, and sustain change.  Simplicity – Develop just enough to get the job done for right now.  Self-organizing teams encourage great architectures, requirements, and designs – Skilled and motivated team members who have decision-making power, take ownership, communicate regularly with other team members, and share ideas that deliver quality products.  Regular reflections on how to become more effective – Self-improvement, process improvement, advancing skills, and techniques help team members work more efficiently.  The intention of Agile is to align development with business needs, and the success of Agile is apparent. Agile projects are customer focused and encourage customer guidance and participation. As a result, Agile has grown to be an overarching view of software development throughout the software industry and an industry all by itself. 1.13 Extreme Programming (XP)  The Extreme Programming is commonly used agile process model.  It uses the concept of object-oriented programming.  A developer focuses on the framework activities like planning, design, coding and testing. XP has a set of rules and practices. 1.13.1 XP Values Following are the values for extreme programming: 1. Communication  Building software development process needs communication between the developer and the customer.  Communication is important for requirement gathering and discussing the concept. 2) Simplicity The simple design is easy to implement in code. 3. Feedback Feedback guides the development process in the right direction. 4. Courage In every development process there will always be a pressure situation. The courage or the discipline to deal with it surely makes the task easy. 5. Respect Agile process should inculcate the habit to respect all team members, other stake holders and customer. 1.13.2 XP Process The XP process comprises four framework activities: 1. Planning  Planning starts with the requirements gathering which enables XP team to understand the rules for the software.  The customer and developer work together for the final requirements. 2. Design  The XP design follows the 'keep it simple' principle.  A simple design always prefers the more difficult representation. 3. Coding  The coding is started after the initial design work is over.  After the initial design work is done, the team creates a set of unit tests which can test each situation that should be a part of the release.  The developer is focused on what must be implemented to pass the test.  Two people are assigned to create the code. It is an important concept in coding activity. 4. Testing  Validation testing of the system occurs on a daily basis. It gives the XP team a regular indication of the progress.  'XP acceptance tests' are known as the customer test. 1.13.3 XP Process Industrial XP Joshua Kerievsky describes Industrial Extreme Programming (IXP) in the following manner: “IXP is an organic evolution of XP. It is imbued with XP’s minimalist, customer-centric, test-driven spirit. IXP differs most from the original XP in its greater inclusion of management, its expanded role for customers, and its upgraded technical practices.” IXP incorporates six new practices that are designed to help ensure that an XP project works successfully for significant projects within a large organization. Readiness assessment. Prior to the initiation of an IXP project, the organization should conduct a readiness assessment. The assessment ascertains whether (1) An appropriate development environment exists to support IXP, (2) The team will be populated by the proper set of stakeholders, (3) The organization has a distinct quality program and supports continuous improvement, (4) The SOFTWARE ENGINEERING RCPIT SHIRPUR 30 organizational culture will support the new values of an agile team, and (5) The broader project community will be populated appropriately. Project community. Classic XP suggests that the right people be used to populate the agile team to ensure success. The implication is that people on the team must be well-trained, adaptable and skilled, and have the proper temperament to contribute to a self-organizing team. When XP is to be applied for a significant project in a large organization, the concept of the “team” should morph into that of a community. A community may have a technologist and customers who are central to the success of a project as well as many other stakeholders (e.g., legal staff, quality auditors, manufacturing or sales types) who “are often at the periphery of an IXP project yet they may play important roles on the project”. In IXP, the community members and their roles should be explicitly defined and mechanisms for communication and coordination between community members should be established. Project chartering. The IXP team assesses the project itself to determine whether an appropriate business justification for the project exists and whether the project will further the overall goals and objectives of the organization. Chartering also examines the context of the project to determine how it complements, extends, or replaces existing systems or processes. Test-driven management. An IXP project requires measurable criteria for assessing the state of the project and the progress that has been made to date. Test-driven management establishes a series of measurable “destinations” and then defines mechanisms for determining whether or not these destinations have been reached. Retrospectives. An IXP team conducts a specialized technical review after a software increment is delivered. Called a retrospective, the review examines “issues, events, and lessons-learned” across a software increment and/or the entire software release. The intent is to improve the IXP process. Continuous learning. Because learning is a vital part of continuous process improvement, members of the XP team are encouraged (and possibly, incented) to learn new methods and techniques that can lead to a higher quality product.  Part – A Software Engineering - Introduction 1. What is Software Engineering? [ND 2013/AM 19] Software engineering is a discipline in which theories, methods and tools are applied to develop professional software product. 2. Write the IEEE Definition Of Software Engineering. [ND 2017] According to IEEE's definition software engineering can be defined as the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software. 3. Define software. Software is a collection of computer programs and related documents that are intended to provide desired features, functionalities and performance. A software can be of two types - 1. Generic software and 2. Custom software. 4. What are two type of software products? There are two types of software products - Generic - These products are developed and to be sold to the range of different customers. Custom - These type of products are developed and sold to the specific group of customers and developed as per their requirements. 5. Software doesn't wear out. Justify. Software does not wear out like hardware, software also similar to hardware shows high failure rate at its initial state. Then it gets modifications and the defects get corrections and thus it comes to the idealized state. Software Process 6. Define Software Process. [ND 2019] Software Process defines a framework for a set of Key Process Areas (KPAs) that must be established for effective delivery of software engineering technology. This establishes the context in which technical methods are applied, work products such as models, documents, data, reports, forms, etc. are produced, milestones are established, quality is ensured, and change is properly managed. 7. Define Software Process Framework. A process framework establishes the foundation for a complete software process by identifying a small number of framework activities that are applicable to all software projects, regardless of size or complexity. It also includes a set of umbrella activities that are applicable across the entire software process. 8. What led to the transition from product oriented development to process oriented development? [MJ 2016] A process framework establishes the foundation for a complete software process by identifying a small number of framework activities that are applicable to all software projects, regardless of size or complexity. It also includes a set of umbrella activities that are applicable across the  entire software process. This led to the transition from product oriented development to process oriented development. 9. Write the Process framework and Umbrella activities. [MJ 2015] A process framework establishes the foundation for a complete software process by identifying a small number of framework activities that are applicable to all software projects, regardless of size or complexity. It also includes a set of umbrella activities that are applicable across the entire software process. Umbrella Activities are 1. Software project tracking and control 2. Formal technical reviews 3. Software quality assurance 4. Software configuration management 5. Document preparation and production 6. Reusability management 7. Measurement 8. Risk management 10. Why software architecture is important in software process? The system architecture defines the role of hardware, software, people, database procedures and other system elements. The architectural design of the system help the developer to understand the system as a whole. Hence system architecture must be built before specifications are completed. Thus architectural design is important in software engineering. 11. What is software process model? On what basis it is chosen? [ND 2016] The software process model can be defined as abstract representation of process. It is based on nature of software project. 12. What is software process? Software process can be defined as the structured set of activities that are required to develop the software system. The fundamental activities are - 1. Specification 2. Design and Implementation 3. Validation 4. Evolution 13. Distinguish between process and methods. [MJ 2014] Software process can be defined as the structured set of activities that are required to develop the software system. Various activities under software process are  Specification  Design and implementation  Validation  Evolution Method is used mainly in object-oriented programming, the term method refers to a piece of code that is exclusively associated either with a class (called class methods) or with an object (called instance methods). 14. Define the terms product and process in software engineering. The process in software engineering can be defined as the structured set of activities that are required to develop software system. Various activities under software process are –  Specification  Design and implementation  Validation  Evolution Perspective and Specialized Process Models 15. What is Linear Sequential Model? Linear Sequential Model. It is also called “Classic Life Cycle” or “Waterfall” model or “Software Life Cycle” suggests a systematic and sequential approach to software development that begins at the system level and progresses through analysis, design, coding, testing and support. 16. What is meant by ‘blocking states’ in linear sequential model? [ND 2014] The linear nature of linear sequential model brings a situation in the project that some project team members have to wait for other members of the team to complete the dependent tasks. This situation is called "blocking state" in linear sequential model. For example, after performing the requirement gathering and analysis step the design process can be started. Hence the team working on design stage has to wait for gathering of all the necessary requirements. Similarly the programmers can not start coding step unless and until the design of the project is completed 17. State the benefits of waterfall life cycle model for software development. The waterfall model is simple to implement. For implementation of small systems the waterfall model is used. 18. List the two deficiencies in waterfall life cycle model. Which process model do you suggest to overcome each deficiency? [MJ 2017] Disadvantages of waterfall model:  Once an application is in the testing stage, it is very difficult to go back and change something that was not well-thought out in the concept stage.  No working software is produced until late during the life cycle.  High amounts of risk and uncertainty.  Not a good model for complex and object-oriented projects.  Poor model for long and ongoing projects.  Not suitable for the projects where requirements are at a moderate to high risk of changing. I would prefer the spiral model in this approach. 19. Define an evolutionary prototype. [ND 2019] Evolutionary Prototyping is a lifecycle model in which the system is developed in increments so that it can readily be modified in response to end-user and customer feedback. 20. Define Prototyping Model. The Prototyping Model is a systems development method (SDM) in which a prototype (an early approximation of a final system or product) is built, tested, and then reworked as necessary until an acceptable prototype is finally achieved from which the complete system or product can now be developed. 21. What are the advantages of prototyping model? [ND 2014] Advantages of prototyping model - The working model of the system can be quickly designed by construction of prototype. This gives the idea of final system to the user. The prototype is evaluated by the user and the requirements can be refined during the process of software development. This method encourages active participation of developer and user. This type of model is cost effective. This model helps to refine the potential risks, associated with the delivery of the final system. The system development speed can be increased with this approach. 22. Define RAD Rapid application development (RAD) is a software development methodology that uses minimal planning in favor of rapid prototyping. A prototype is a working model that is functionally equivalent to a component of the product. 23. What are the phases encompassed in the RAD model? Various phases in the RAD model are 1. Business modelling 2. Data modelling 3. Process modelling 4. Application generation 5. Testing and turnover 24. What are the drawbacks of rapid application development life cycle model? Disadvantages of RAD model:  Depends on strong team and individual performances for identifying business requirements.  Only system that can be modularized can be built using RAD  Requires highly skilled developers/designers.  High dependency on modeling skills  Inapplicable to cheaper projects as cost of modeling and automated code generation is very high 25. Define Agile? The word ‘agile’ means −  Able to move your body quickly and easily.  Able to think quickly and clearly. 26. What agile manifesto states? The Agile Manifesto states that − We are uncovering better ways of developing software by doing it and helping others do it. Through this work, we have come to value −  Individuals and interactions over processes and tools.  Working software over comprehensive documentation.  Customer collaboration over contract negotiation.  Responding to change over following a plan 27. Define Agile process.  This approach is rigid, that means if requirements get changed, then rework was essential. Hence new methods were proposed in 1990;s which are known as agile process.  The agile processes are the light-weight methods are people –based rather than plan based methods.  The agile process forces the development team to focus on software itself rather than design and documentation.  The agile process believes in iterative method.  The aim of agile process is to deliver the working model of software quickly to the customer. For Eg: Extreme programming is the best known of agile process 28. What the Agile Methodology states?  The agile method proponents claim that if the software development is carried out using the agile approach then it will allow the software team to accommodate changes late in a software project without dramatic cost and time impact.  In other words, if the incremental delivery is combined with agile practices such as continuous unit testing and pair programming then the cost of changes can be controlled.  The following graph represents how the software development approach has a strong influence on the development cost due to changes suggested. 29. State the Twelve Agile Manifesto Principles  Customer satisfaction through early and continuous software delivery  Accommodate changing requirements throughout the development process  Frequent delivery of working software  Collaboration between the business stakeholders and developers throughout the project  Support, trust, and motivate the people involved  Enable face-to-face interactions  Working software is the primary measure of progress  Agile processes to support a consistent development pace  Attention to technical detail and design enhances agility  Simplicity  Self-organizing teams encourage great architectures, requirements, and  Regular reflections on how to become more effective 30. What is extreme programming?  The Extreme Programming is commonly used agile process model.  It uses the concept of object-oriented programming.  A developer focuses on the framework activities like planning, design, coding and testing. XP has a set of rules and practices. 31. What are the XP values?  Communication  Simplicity  Feedback  Courage  Respect 32. What are the four main framework activities that XP process compromises  Planning  Design  Coding  Testing 33. List any two agile process model. [AM 2019]  Extreme Programming (XP)  Adaptive Software Development (ASD)  Dynamic Systems Development Method (DSDM)  Scrum.  Crystal.  Feature Driven Development (FDD) PART B Questions Bank Q.No Questions Univ. QP Explain in detail what Software Engineering is and list out various 1. [ND 2017] characteristics of a Software Write a short note on various goals and objectives of software being 2. [MJ 2012] engineered and the challenges encountered while engineering software. Discuss in detail what does the term “Software Crisis” mean to software 3. developers Write a short note on Layered Technology being followed in software 4. engineering by explaining the software process Elucidate the key features of the software process models with Suitable a 5. [MJ 2016] Example Identify the umbrella activities in software engineering process and [ND 2017] 6. explain them in detail Explain the CMMI Model to assess the organization level. [ND 2017] 7. [ND 2015] WHAT is a process model? Describe the process model that you would [MJ 2017] 8. choose to manufacture a car. Explain giving suitable reasons. [ND15/16] Discuss linear sequential model in detail along with its advantages and disadvantages [MJ 2012] 9. [OR] [MJ 2016] Explain the Software Development Life Cycle using simple waterfall model. Describe the situations where iterative enhancement model might lead to 10. [MJ 2016] difficulties. Explain in detail how Incremental Model of Software development is 11. carried out. 12. Write a short note on RAD model and which type of applications suit [MJ 2015]  RAD model? Justify your answer. [OR] Neatly explain the Rapid Application Development process models and write their advantages and disadvantages. Discuss the prototyping model. What is the effect of designing a 13. [MJ 2016] prototype on the overall cost of the software project With suitable illustration explain about SPIRAL model evolutionary software development. [OR] [MJ 2015] Neatly explain the spiral process models and write their advantages and 14. [ND 2017] disadvantages [ND 2016] [OR] Which process model is best suited for risk management? Discuss with an example. Give the advantages and disadvantages. Explain the Component based Software development with a neat a 15. [ND 2017] sketch. 16. Explain Agile Process in detail? 17. Describe in detail Extreme Programming. 18. Explain Industrial Xp. Compare the waterfall, prototyping and spiral model. List the features of [MJ 2019] 19. each model, advantages and disadvantages and a type of application where the model will be acceptable. Define Agility.List any five principles of agility(5 marks) [MJ 2019] 20. Explain the phases in extreme programming process(8 Marks) 21. What is agility? Elaborate the agile principles. [ND 2019] 22. Outline the Spiral life cycle model with a diagram. [ND 2019]