Download to read offline
More Related Content
Similar to Chapter 1 Introduction to Software Engineering and Process Models.pdf
Chapter 1 Introduction to Software Engineering and Process Models.pdf
- 1. Chapter 1 Introduction toSoftware Engineering and Process Models Megha V Gupta, NHITM
- 2. What is SoftwareEngineering? Software is more than just a program code. A program is an executable code, which serves some computational purpose. Software is considered to be a collection of executable programming code, associated libraries, and documentation. Software, when made for a specific requirement is called a software product Engineering, on the other hand, is all about developing products, using well-defined, scientific principles and methods. Engineering Software 2
- 3. 3 Software is: Software is: (1)instructions (computer programs) that when executed provide desired features, function, and performance (2) data structures that enable the programs to adequately manipulate information and (3) documentation that describes the operation and use of the programs
- 4. Software Engineering -Defined (IEEE) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software (1969) Software engineering is the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines Fritz Bauer, a German computer scientist, defines software engineering as: We can define software engineering as an engineering branch associated with the development of software product using well-defined scientific principles, methods and procedures. The outcome of software engineering is an efficient and reliable software product.
- 5. NEED OF SOFTWAREENGINEERING 9 13 5 6 4 2 Large software Cost Quality Management Scalability Dynamic Nature Reduce Complexity
- 6. 6 The need forsoftware engineering arises because of a higher rate of change in user requirements and environment in which the software is working. ❖Large software - It is easier to build a wall than a house or building, likewise, as the size of software becomes large, engineering has to step to give it a scientific process. ❖ Scalability- If the software process were not based on scientific and engineering concepts, it would be easier to re-create new software than to scale an existing one. ❖Cost- As the hardware industry has shown its skills and huge manufacturing has lowered the price of computer and electronic hardware. But the cost of the software remains high if the proper process is not adapted. NEEDOF SOFTWAREENGINEERING
- 7. ❖Dynamic Nature- Thealways growing and adapting nature of software hugely depends upon the environment in which the user works. If the nature of software is always changing, new enhancements need to be done to the existing one. This is where software engineering plays a good role. ❖Quality Management- The better process of software development provides better and quality software products. ❖Reduce Complexity- Big software is always complicated and challenging to progress. Software engineering has a great solution to reduce the complication of any project. Software engineering divides big problems into various small issues. And then start solving each small issue one by one. All these small problems are solved independently of each other. NEEDOF SOFTWAREENGINEERING
- 8. CHARACTERISTICS OF AGOOD SOFTWARE Operational 8 Transitional Maintenance
- 9. Operational 9 Budget Usability Efficiency Correctness Functionality Dependability Security Safety In operational categories,the factors that decide the software performance in operations. It can be measured on:
- 10. Transitional 1 0 Portability Interoperability Reusability Adaptability When the softwareis moved from one platform to another, the factors deciding the software quality:
- 11. Maintenance 1 1 Modularity Maintainability Flexibility Scalability In this categoryall factors are included that describe how well a software has the capabilities to maintain itself in the ever-changing environment:
- 12. Software Engineering: ALayered Technology • Any engineering approach must rest on an organizational commitment to quality. • The bedrock that supports Software Engineering is a quality focus. • Quality is the “degree of goodness”. It cant be measured directly. It should have the following characteristics: Correctness, Maintainability, Integrity, and Usability.
- 13. A quality focus: •It defines the continuous process improvement principles of software. • It provides integrity which means providing security to the software so that data can be accessed by only an authorized person, no outsider can access the data. • It also focuses on maintainability and usability. Process: • It is the foundation or base layer of software engineering. • It is the key that binds all the layers together which enables the development of software before the deadline or on time. • Process defines a framework that must be established for the effective delivery of software engineering technology. The software process covers all the activities, actions, and tasks required to be carried out for software development. Software Engineering: A Layered Technology
- 14. Method: • During theprocess of software development the answers to all “how-to-do” questions are given by method. • It has the information on all the tasks which include communication, requirement analysis, design modeling, program construction, testing, and support. Tools: • Software engineering tools provide a self-operating system for processes and methods. • Tools are integrated which means information created by one tool can be used by another. • Provide automated or semi-automated support for the process and methods (i.e., Computer-aided software engineering CASE tools) Software Engineering: A Layered Technology
- 15. What is aProcess? (Webster) A system of operations in producing something; a series of actions, changes, or functions that achieve an end or a result (IEEE) A sequence of steps performed for a given purpose •A process is a collection of activities, actions, and tasks that are performed when some work product is to be created • A process is not a rigid prescription for how to build thesoftware rather it is an adaptable approach that enables the people doing the work to pick and choose the appropriate set of work actions and tasks
- 16. Software Process/ SoftwareProcess Framework • A Software Engineering process is the model selected for managing the creation of software from customer initiation to the release of the finished product. • Software process models can be prescriptive or agile, complex or simple, all-encompassing or targeted, but in every case, 5 key activities must occur. • The framework activities are applicable to all projects and all applications domains, and they are a template for every process model The framework is a standard way to build anddeploy applications. ▪ It is a foundation of the complete software engineering process. ▪ Includes a set of umbrella activities. 1 6
- 17. Process framework • Eachframework activity is populated by a set of software engineering actions • Each action is populated with individual work tasks that accomplish some part of the work implied by the action. • Each Software Engineering action is represented by a number of different task sets, each a collection of Software Engineering work tasks, related work products, quality assurance points, and project milestones. • The task set that best accommodates the needs of the project and the characteristics of the team is chosen.
- 18. Generic Process Framework 1 8 Thefollowing generic process framework is applicable to the vast majority of s/w projects
- 19. Ageneric process frameworkencompasses five activities which are given below one byone: 1 2 3 1 9
- 20. Ageneric process frameworkencompasses five activities which are given below one byone: 4 5 2 0
- 21. Umbrella Activities • Theframework described in the generic view of Software Engineering is complemented by a number of umbrella activities • Umbrella activities are a set of procedures that the software engineering team follows to maintain the progress, quality, change and risks of the overall development tasks. • These steps of umbrella activities will evolve through the phases of a generic view of software development.
- 22. Umbrella Activities 1. SoftwareProject Tracking and Control 2. Formal Technical Reviews 3. Software QualityAssurance 4. Software Configuration Management 5. Document Preparationand Production 6. Re-usability Management 7. Measurement and Metrics 8. Risk Management
- 23.
- 24. Immature Software Organizations •Software processes are generally improvised • If a process is specified, it is not rigorously followed or enforced • The software organization is reactionary • Managers only focus on solving immediate (crisis) problems • Schedules and budgets are routinely exceeded because they are not based on realistic estimates • When hard deadlines are imposed, product functionality and quality are often compromised • There is no basis for judging process quality or for solving product or process problems • Activities such as reviews and testing are curtailed or eliminated when projects fall behind schedule
- 25. What is CMM? •CMM: Capability Maturity Model • Developed in 1987 by the Software Engineering Institute (SEI) at Carnegie- Mellon University under the sponsorship of DARPA • A methodology used to develop and refine an organization’s software development process. • Describes a 5-level evolutionary improvement path for software organizations from an Adhoc, immature process to a mature, disciplined one. • The Capability Maturity Model (CMM) was first defined in 1989 in the book “Managing Software Processes” by Watts Humphrey. • It was originally developed by the US Department of Defence to gauge whether government contractors were able to successfully complete software projects.
- 26. 29 Capability Maturity Model(CMM) Overview ❑Its core theory is based on the premise that high-quality software can only be produced by high-quality processes. In theory, this allows developers to repeat their successes and avoid repeating their failures. ❑Provides guidance on how to gain control of processes for developing and maintaining software and how to evolve toward a culture of software engineering and management excellence. ❑This concept of assessing an organization’s maturity on a specific capability can be applied in any area of a business where processes are required to mature overtime. ❑As an organization matures, the software process becomes better defined and more consistently implemented throughout the organization ❑Software process maturity is the extent to which a specific process is explicitly defined, managed, measured, controlled, and effective
- 27. 5 Levels ofCMM 27 Stage 1: During the Initial stage, processes are ad-hoc, inconsistent, and even chaotic. There are very few formal processes and success is based upon individual effort. This is the starting point of defining processes. Stage 2: During the Repeatable stage, basic and consistent processes are established. The processes are repeated for similar projects. Stage 3: During the Defined stage, all processes are well defined, documented, standardized, and integrated usually into software for the entire organization. Consistent practices are inplace.
- 28. 5 Levels ofCMM Stage 4: During the Managed stage, strategic analysis is performed through data collected on the quality of processes. Software and processes are clearly quantified. Stage 5: During the Optimizing stage, pro-active process improvement is implemented through qualitative feedback. This helps in developing new ideas and technologies.
- 29. Characteristics of EachLevel Initial Level (Level 1) • Characterized as ad hoc, and occasionally even chaotic • Few processes are defined, and success depends on individual effort Repeatable (Level 2) • Basic project 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 Defined (Level 3) • 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 and maintaining software Managed (Level 4) • Detailed measures of the software process and product quality are collected • Both the software process and products are quantitatively understood and controlled Optimized (Level 5) • Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies
- 31.
- 32. LIMITATIONS OF THECMM 32 The model was developed to evaluate the capability of government contractors to develop software. In real life, however, well- documented processes and procedures do not necessarily create successful software projects.
- 33. Software Process Models •To solve actual problems in an industry setting, a software engineer or a team of engineers must incorporate a development strategy that encompasses the process, methods, and tools layers and the generic phases. This strategy is often referred to as a process model or a software engineering paradigm. • A process model for software engineering is chosen based on the nature of the project and application, the methods and tools to be used, and the controls and deliverables that are required. • A software process model is an abstract representation of a process. It presents a description of a process.
- 34. Process description • Whenwe describe and discuss processes, we usually talk about the activities in these processes such as specifying a data model, designing a user interface, etc., and the ordering of these activities. • Process descriptions may also include: o Products, which are the outcomes of a process activity; o Roles, which reflect the responsibilities of the people involved in the process; o Pre- and post-conditions, which are statements that are true before and after a process activity has been enacted or a product produced. o Notation: activities, products
- 35. 35 Prescriptive Process Models •Defines a distinct set of activities, actions, tasks, milestones, and work products that are required to engineer high-quality software. • Prescriptive process models advocate an orderly approach to Software Engineering. 1) The Waterfall model 2) Incremental model 3) Evolutionary process model 4) Specialized process model • These process models are called “prescriptive” because they prescribe a set of process elements—framework activities, software engineering actions, tasks, work products, quality assurance, and change control mechanisms for each project. • Each process model also prescribes a process flow (also called a workflow)—that is, the manner in which the process elements are interrelated to one another.
- 36. 36 Waterfall Model (Diagram) Communication Project initiation Requirements gathering Planning Estimating Scheduling TrackingModeling Analysis Design Construction Code Test Deployment Delivery Support Feedback
- 37. 37 Waterfall Model (Description) • Oldestsoftware lifecycle model and best understood by upper management • Used when requirements are well understood and risk is low • Work flow is in a linear (i.e., sequential) fashion • Used often with well-defined adaptations or enhancements to current software Many people dismiss the waterfall as obsolete and it certainly does have problems. But this model can still be used in some situations.
- 38. 38 Waterfall Model (Problems) • Doesn'tsupport iteration, so changes can cause confusion • Difficult for customers to state all requirements explicitly and upfront • Requires customer patience because a working version of the program doesn't occur until the final phase • Problems can be somewhat alleviated in the model through the addition of feedback loops (see the next slide)
- 39. 39 Waterfall Model withFeedback (Diagram) Communication Project initiation Requirements gathering Planning Estimating Scheduling Tracking Modeling Analysis Design Construction Code Test Deployment Delivery Support Feedback
- 40. Incremental Process Models 40 • Tendto be among the most widely used (and effective) in the industry. • It combines elements of the waterfall model applied in an iterative fashion. The model applies linear sequences in a staggered fashion as calendar time progresses. • Each linear sequence produces deliverable “increments” of the software. (Ex: a Word Processor delivers basic file mgmt., and editing, in the first increment; more sophisticated editing, and document production capabilities in the 2nd increment; spelling and grammar checking in the 3rd increment. • When an increment model is used, the 1st increment is often a core product. The core product is used by the customer. • 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.
- 41.
- 42. 42 Incremental Model (Description) • Usedwhen requirements are well understood • Multiple independent deliveries are identified • Work flow is in a linear (i.e., sequential) fashion within an increment and is staggered between increments • Iterative in nature; focuses on an operational product with each increment • Provides a needed set of functionality sooner while delivering optional components later • Useful also when staffing is too short for a full-scale development
- 43. Incremental Process Model 43 •The process is repeated following the delivery of each increment until the complete product is produced. • If the customer demands delivery by a date that is impossible to meet, suggest delivering one or more increments by that date and the rest of the Software later.
- 44. 44 Incremental Process Model ❖Oncethe customer assesses the core product, there is a plan developed for the next increment. Thus, in every increment, the needs of the client are kept in mind, more features and functions are added, and the core product is updated. ❖This process continues until the complete product is produced. ❖The increments earlier to the main increment are called “stripped down” versions of the final product. These increases form a base for customer evaluation. On this basis, the client can suggest new requirements if required. ❖If there are a smaller number of employees to work on the project, the Incremental development model is extremely useful to complete the project before the deadline. In a project, early increments can be done with a smaller number of people. ❖In case the core product is well-defined and understood, more employees could be added if needed in future increments. ❖ One of the benefits of the Incremental process model is that it can be planned to manage technical risks.
- 45. 45 Advantages of IncrementalModel ❖ Initial product delivery is faster. ❖ Lower initial delivery cost. ❖ The core product is developed first i.e. main functionality is added in the first increment. ❖After each iteration, regression testing should be conducted. During this testing, faulty elements of the software can be quickly identified because few changes are made within any single iteration. ❖It is easier to test and debug than other methods of software development because smaller changes are made during each iteration. This allows for more targeted and rigorous testing of each element within the overall product. ❖ With each release, a new feature is added to theproduct. ❖ Customers can respond to features and review theproduct. ❖ Risk of changing requirements is reduced ❖ The workload is less. Disadvantages of Incremental Model ❖Requires good analysis. ❖Resulting cost may exceed the cost of the organization. ❖Each phase of an iteration is rigid and does not overlap eachother ❖As additional functionality is added to the product, problems may arise related to system architecture which was not evident in earlier prototypes.
- 46. What are theadvantages of an incrementalmodel? • Customer feedback is received after the delivery of eachcomponent. • Risk of requirement changes is reduced • More flexible • Easy to test and debug • Give quick results What are the disadvantages of an incrementalmodel? • Needs a proper plan to integrate thecomponents • Needs a proper design to integrate thecomponents • More expansive as compared to the waterfallmodel. When to use the incrementalmodel? •When major requirements are understood but some requirements can evolve within the passage of time. • When product launch in the market is gettinglate. •When a customer has no problem with the budget but he demands more and more quality in software. 46
- 47. Difference Between Waterfalland Incremental Model 47
- 48. RAD Model • RapidApplication Development (RAD) is an incremental software process model that emphasizes a short development cycle. • RAD is a “high-speed” adaptation of the waterfall model, in which rapid development is achieved by using a component- based construction approach. • If requirements are well understood and project scope is constrained, the RAD process enables a development team to create a fully functional system within a short period of time.
- 49. RAD Model Communicat ion Planning Modeling business modeling dat a modeling process modeling Const ruct ion component reuse aut omat ic code generat ion t est ing De ployme nt 6 0 - 9 0 days Team # 1 Mo d eling business m odeling dat a m odeling process m odeling Co nst ruct io n com ponent reuse aut om at ic code generat ion t est ing M o d e lin g business m odeling data m odeling process m odeling Co n st ru ct io n com ponent reuse autom atic code generation testing Team # 2 Team # n int egrat ion delivery feedback
- 50. What are thedrawbacks of the RAD model? • For large, but scalable projects, RAD requires sufficient human resources to create the right number of RAD teams. • If developers and customers are not committed to the rapid- fire activities necessary to complete the system in a much abbreviated time frame, the RAD project will fail. • If a system cannot properly be modularized, building the components necessary for RAD will be problematic.
- 51. Evolutionary Process Models •Software evolves over a period of time; business and product requirements often change as development proceeds, making a straight-line path to an end product unrealistic. • Software Engineering needs a process model that has been explicitly designed to accommodate a product that evolves over time. • Evolutionary process models are iterative. They produce increasingly more complete versions of the Software with each iteration
- 52. Quiz RAD stands for a)Relative Application Development b) Rapid Application Development c) Rapid Application Document d) None of the mentioned
- 53. Quiz If you werea lead developer of a software company and you are asked to submit a project/product within a stipulated time-frame with no cost barriers, which model would you select? a) Waterfall b) Spiral c) RAD d) Incremental
- 54. Quiz Which of thefollowing activities of a Generic Process framework provides a feedback report? a) Communication b) Planning c) Modeling & Construction d) Deployment
- 55. Quiz Which one ofthe following is not an Umbrella Activity a) Reusability management b) Risk management c) Measurement d) User Reviews
- 56. 56 Prototyping Model (Diagram) Communication Quick Planning Modeling Quick Design Construction OfPrototype Deployment, Delivery, and Feedback Start
- 57. Prototyping Model • Customersoften define a set of general objectives for software but don’t identify detailed input, processing, or input requirements. • Prototyping paradigm assists the Software engineering and the customer to better understand what is to be built when requirements are fuzzy. • The prototyping paradigm begins with communication where the requirements and goals of Software are defined. • Prototyping iteration is planned quickly and modeling in the form of quick design occurs. • Follows an evolutionary and iterative approach • Used when requirements are not well understood • Serves as a mechanism for identifying software requirements • Focuses on those aspects of the software that are visible to the customer/user • Feedback is used to refine the prototype
- 58. 58 Prototyping Model (Description) •The quick design focuses on a representation of those aspects of the Software that will be visible to the customer “Human interface”. • The quick design leads to the Construction of the Prototype. • The prototype is deployed and then evaluated by the customer. • Feedback is used to refine requirements for the Software. • Iteration occurs as the prototype is tuned to satisfy the needs of the customer while enabling the developer to better understand what needs to be done. Communicat ion Quick plan Const ruct ion of prot ot ype Mode ling Quick de sign Delivery & Feedback Deployment
- 59. Prototyping Model (Problemsand Lessons) The prototype can serve as the “first system”. Both customers and developers like the prototyping paradigm as users get a feel for the actual system, and developers get to build Software immediately. Yet, prototyping can be problematic: a. The customer sees a "working version" of the software, wants to stop all development, and then buys the prototype after a "few fixes" are made b. Developers often make implementation compromises to get the software running quickly (e.g., language choice, user interface, operating system choice, inefficient algorithms) Lesson learned • Define the rules upfront on the final disposition of the prototype before it is built • In most circumstances, plan to discard the prototype and engineer the actual production software with a goal of quality
- 60. Spiral Model 60 communication planning modeling construction deployment delivery feedback start analysis design code test estimation scheduling risk analysis Thespiral model is an evolutionary software process model that couples the iterative nature of prototyping with the controlled and systematic aspects of the waterfall model. It has two distinguishing features: a. A cyclic approach for incrementally growing a system’s degree of definition and implementation while decreasing its degree of risk. b. A set of anchor point milestones for ensuring stakeholder commitment to feasible and mutually satisfactory solutions. • Anchor-point milestones – a combination of work products and conditions that are attained along the path of the spiral- are noted for each evolutionary pass.
- 61. 61 Spiral Model (Description) •Invented by Dr. Barry Boehm in 1988 • Follows an evolutionary approach • Used when requirements are not well understood and risks are high • Inner spirals focus on identifying software requirements and project risks; may also incorporate prototyping. Outer spirals take on a classical waterfall approach after requirements have been defined, but permit iterative growth of the software • Operates as a risk-driven model…a go/no-go decision occurs after each complete spiral in order to react to risk determinations • Requires considerable expertise in risk assessment • Serves as a realistic model for large-scale software development
- 62. Quiz __________ is notsuitable for accommodating any change? a) RAD Model b) Waterfall Model c) Build & Fix Model d) Prototyping Model
- 63. Quiz The major drawbackof RAD model is __________. 1.It requires highly skilled developers/designers. 2.It necessitates customer feedbacks. 3.It increases the component reusability. 4.Both (a) & (c)
- 64. Quiz The spiral modelwas originally proposed by a) IBM b) Barry Boehm c) Pressman d) Royce
- 65. Spiral Model • Duringthe early stages, the 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 set of framework activities divided by the Software engineering team. • As this evolutionary process begins, the Software team performs activities that are implied by a circuit around the spiral in a clockwise direction, beginning at the center. • Risk is considered as each revolution is made.
- 66. Spiral Model • Thefirst circuit around the spiral might result in the development of a product specification; subsequent passes around the spiral might be used to develop a prototype and then progressively more sophisticated versions of the Software. • Each pass through the planning region results in adjustments to the project plan. Cost and schedule are adjusted based on feedback derived from the customer after delivery. • Unlike other process models that end when Software is delivered, the spiral model can be adapted to apply throughout the life of the Software. communication planning modeling construction deployment delivery feedback start analysis design code test estimation scheduling risk analysis
- 68. Agile Methodologies • Theprofessional goal of every software engineer, and every development team, is to deliver the highest possible value to our employers and customers. And yet, our projects fail or fail to deliver value, at a dismaying rate. • Though well-intentioned, the upward spiral of process inflation is culpable for at least some of this failure. • The principles and values of agile software development were formed as a way to help teams break the cycle of process inflation and focus on simple techniques for reaching their goals. • At the time of this writing there were many agile processes to choose from. These include SCRUM, Crystal, Feature Driven Development (FDD), Adaptive Software Development (ADP), and most significantly, Extreme Programming (XP). Others…
- 69. Agile Methodologies • Aswe came to know that traditional software development approaches are more mechanistic and concentrate more on Processes, tools, contracts, and plans. In contrast to traditional methods, agile methods keep the emphasis on interaction, working software, embracing change at any moment of the project, and customer relationships. • The method can be agile if it is: Incremental Cooperative Straightforward Adaptive • “Agile view is more people-centric rather than plan-centric.” Agile methods are not defined by a small set of principles, practices, and techniques. It creates a strategic capability that has the capability of responding to change, the capability to balance the structure and flexibility, capability of innovation and creation through development team and uncertainty.
- 70. Agile methods • Dissatisfactionwith the overheads involved in software design methods of the 1980s and 1990s led to the creation of agile methods. These methods: • Focus on the code rather than the design • Are based on an iterative approach to software development • Are intended to deliver working software quickly and evolve this quickly to meet changing requirements. • The aim of agile methods is to reduce overheads in the software process (e.g. by limiting documentation) and to be able to respond quickly to changing requirements without excessive rework.
- 71. Agile manifesto • Weare 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.
- 72. 72 12Principles of AgileManifesto 1.The first principle is to take a customer-oriented approach and keep them updated. 2.Make changes whenever and wherever required, even at the end of the development stage for any competitive changes. 3.Delivering the software to customers on time with more flexibility. 4.Collaboration between Business and development teams. 5.Give support and motivation to the team member who shows interest in the project. Give them that extra work they would like to do, and trust them to get the job done. 6.Have a face-to-face interaction with the team. 7.Working software is the primary measure of progress. 8.Agile processes promote sustainable development forall. 9.Continuous attention to technical excellence and good design enhancesagility. 10.The simplicity of the agile environment. 11.The best practices come from self-organizing teams. 12.Work effectively within cross-functionalteams.
- 75. 75 Important Aspects ofAgile Project Management To create a meaningful iteration asking with the Software development cycles. The 4 major points created a way more transparency in the project approach for success. ● Team Interaction: In the software development process, rather than just told and processes, there is a need for team Interaction. That is when a project can lead to success in a very efficient way. ● Simplified Approach: Agile methodology is based on working on chunks called ”sprints”. This leads to a simplified approach to continuous development. ● Customer Collaboration: The customer’s involvement in the project plays a very important role in Agile management so that the project is customer-oriented. ● Respond to the Immediate Changes: If there are any changes made during any of the development stages. Immediate changes can be implemented in agile.
- 76. Extreme Programming • Avery influential agile method, developed in the late 1990s, that introduced a range of agile development techniques. • Extreme Programming (XP) takes an ‘extreme’ approach to iterative development. New versions may be built several times per day; Increments are delivered to customers approx. every 2 weeks; All tests must be run for every build and the build is only accepted if tests run successfully. 15
- 77. Extreme Programming ❖ XPis a lightweight, Efficient, Low risk, Flexible, predictable, scientific, and fun way to develop a software ❖ Small to a medium team that works under vague and rapidly changing requirements ❖ It follows Object Oriented Approach
- 78. Values of extremeprogramming XP has simple rules that are based on 5 values to guide teamwork: 1. Communication. XP stresses the importance of the appropriate kind of communication – face-to-face discussion with the aid of a whiteboard or other drawing mechanism. 2.Simplicity. Developers strive to write simple code bringing more value to a product, as it saves time and effort. Simplicity also means address only the requirements that you know about; don’t try to predict the future. 3.Feedback. Team members deliver software frequently, get feedback about it, and improve a product according to the new requirements. 4.Courage. Programmers objectively evaluate their own results without making excuses and are always ready to respond to changes. You need the courage to raise organizational issues that reduce your team’s effectiveness. You need the courage to stop doing something that doesn’t work and try something else. You need the courage to accept and act on feedback, even when it’s difficult to accept. Respect. The members of your team need to respect each other in order to communicate with each other, provide and accept feedback that honors your relationship, and work together to identify simple designs and solutions.
- 79. XP Fundamentals byKent Beck • Write unit tests before programming; keeping all tests running at all times. • Integrating and testing the whole system--several times a day. • Producing all software in pairs, two programmers at one screen. • Starting projects with simple design. A simple design can evolve. • Putting a minimal system into production quickly and growing it in whatever directions prove most valuable.
- 80. XP and AgilePrinciples Incremental development is supported through small, frequent system releases. Customer involvement means full-time customer engagement with the team. People not process through pair programming, collective ownership, and a process that avoids long working hours. Change supported through regular system releases. Maintaining simplicity through constant refactoring of code. 16
- 81. Influential XP practices •Extreme programming has a technical focus and is not easy to integrate with management practice in most organizations. • Consequently, while agile development uses practices from XP, the method as originally defined is not widely used. • Key practices • User stories for specification • Refactoring • Test-first development • Pair programming
- 82. 1.User stories forrequirements • In XP, a customer or user is part of the XP team and is responsible for making decisions on requirements. • User requirements are expressed as user stories or scenarios. • These are written on cards and the development team breaks them down into implementation tasks. These tasks are the basis of schedule and cost estimates. • The customer chooses the stories for inclusion in the next release based on their priorities and the schedule estimates.
- 83. 2. Refactoring XP proposesconstant code improvement (refactoring) to make changes easier when they have to be implemented. Programming team looks for possible software improvements and makes these improvements even where there is no immediate need for them. This improves the understandability of the software and so reduces the need for documentation. Changes are easier to make because the code is well-structured and clear. However, some changes require architecture refactoring and this is much more expensive. RISK: Changes the user does not test Changes to working software break it
- 84. Examples of refactoring Re-organizationof a class hierarchy to remove duplicate code. Tidying up and renaming attributes and methods to make them easier to understand. The replacement of inline code with calls to methods that have been included in a program library.
- 85. 3. Test-first development Insteadof following the normal path of: develop code -> write tests -> run tests The practice of Test-First Programming follows the path of: Write failing automated test -> Run failing test -> develop code to make test pass -> run test -> repeat Test-First Programming reduces the feedback cycle for developers to identify and resolve issues, thereby decreasing the number of bugs that get introduced into production.
- 86. Problems with test-firstdevelopment • Programmers prefer programming to testing and sometimes they take shortcuts when writing tests. For E.g. they may write incomplete tests that do not check for all possible exceptions that may occur. • Some tests can be very difficult to write incrementally. E.g., in a complex user interface, it is often difficult to write unit tests for the code that implements the ‘display logic’ and workflow between screens. • It is difficult to judge the completeness of a set of tests. Although you may have a lot of system tests, your test set may not provide complete coverage.
- 87. 4. Pair programming •Pair programming involves programmers working in pairs, and developing code together. • This helps develop common ownership of code and spreads knowledge across the team. • It serves as an informal review process as each line of code is looked at by more than 1 person. • It encourages refactoring as the whole team can benefit from improving the system code.
- 88. Pair Programming In pairprogramming, programmers sit together at the same workstation to develop the software. Pairs are created dynamically so that all team members work with each other during the development process. The sharing of knowledge that happens during pair programming is very important as it reduces the overall risks to a project when team members leave. Pair programming is not necessarily inefficient and there is evidence that a pair working together is more efficient than 2 programmers working separately.
- 89. The extreme programmingrelease cycle
- 90. Extreme programming practices(a) Principle or practice Description Incremental planning Requirements are recorded on story cards and the stories to be included in a release are determined by the time available and their relative priority. The developers break these stories into development ‘Tasks’. Small releases The minimal useful set of functionality that provides business value is developed first. Releases of the system are frequent and incrementally add functionality to the first release. Simple design Enough design is carried out to meet the current requirements and no more. Test-first development An automated unit test framework is used to write tests for a new piece of functionality before that functionality itself is implemented. Refactoring All developers are expected to refactor the code continuously as soon as possible code improvements are found. This keeps the code simple and maintainable.
- 91. Extreme programming practices(b) Pair programming Developers work in pairs, checking each other’s work and providing the support to always do a good job. Collective ownership The pairs of developers work on all areas of the system, so that no islands of expertise develop and all the developers take responsibility for all of the code. Anyone can change anything. Continuous integration As soon as the work on a task is complete, it is integrated into the whole system. After any such integration, all the unit tests in the system must pass. Sustainable pace Large amounts of overtime are not considered acceptable as the net effect is often to reduce code quality and medium term productivity On-site customer A representative of the end-user of the system (the customer) should be available full time for the use of the XP team. In an extreme programming process, the customer is a member of the development team and is responsible for bringing system requirements to the team for implementation.
- 92. Scrum • Scrum isan agile method that focuses on managing iterative development rather than specific agile practices. • Three phases in Scrum. • The initial phase is an outline planning phase where you establish the general objectives for the project and design the software architecture. • This is followed by a series of sprint cycles, where each cycle develops an increment of the system. • The project closure phase wraps up the project, completes required documentation such as system help frames and user manuals, and assesses the lessons learned from the project. • The term scrum is borrowed from rugby, where it is a formation of players. The term scrum was chosen by the paper's authors because it emphasizes teamwork. The software development term scrum was first used in a 1986 paper titled "The New New Product Development Game" by Hirotaka Takeuchi and Ikujiro Nonaka. The paper was published in the Jan 1986 issue of Harvard Business Review.
- 93. Scrum • Scrum isa highly iterative agile framework that operates in sprints of 2-4 weeks. • It defines features and objectives prior to each sprint and is designed to reduce risk while providing value to customers as quickly as possible. • In each sprint, a team commits to completing several user stories – brief descriptions of what a user needs to be able to achieve with the software.
- 95. Scrum Framework The primarystages in the scrum process are: 1.Creating a product backlog – a prioritized list of development tasks, defined as user stories. The work required for each user story is estimated using hours or story points. 2.Sprint planning – creating a sprint backlog – a subset of the product backlog planned for a specific sprint, and estimated to fit into the fixed time scope of the sprint. 3.Sprint work – developing working software within the sprint. The team carries out a daily stand-up meeting to share progress and resolve problems experienced by the team. 4.Testing and product demonstration – towards the end of a sprint, the focus shifts to stabilizing and finalizing features, and conducting acceptance testing with product owners and customers. 5.Retrospective – at the end of the sprint, sharing lessons learned from the previous sprint and using it to plan or adjust the backlog for the next sprint.
- 97. The Scrum sprintcycle • The starting point for planning is the product backlog, which is the list of work to be done on the project. • The selection phase involves all of the project team who work with the customer to select the features and functionality from the product backlog to be developed during the sprint. • Once these are agreed upon, the team organizes themselves to develop the software.
- 98.
- 99. The Sprint cycle •During this stage the team is isolated from the customer and the organization, with all communications channeled through the ‘Scrum master’. • The role of the Scrum master is to protect the development team from external distractions. • At the end of the sprint, the work done is reviewed and presented to stakeholders. The next sprint cycle then begins.
- 100. Teamwork in Scrum •The ‘Scrum master’ is a facilitator who arranges daily meetings, tracks the backlog of work to be done, records decisions measures progress against the backlog, and communicates with customers and management outside of the team. • The whole team attends short daily meetings (Scrums) where all team members share information, describe their progress since the last meeting, problems that have arisen, and what is planned for the following day. • This means that everyone on the team knows what is going on and, if problems arise, can re-plan short-term work to cope with them.
- 101. Sprint Retrospective This exerciseallows you to reallocate time and resources to where it matters the most.
- 102. Scrum benefits The productis broken down into a set of manageable and understandable chunks. Unstable requirements do not hold up progress. The whole team has visibility of everything and consequently team communication is improved. Customers see on-time delivery of increments and gain feedback on how the product works. Trust between customers and developers is established and a positive culture is created in which everyone expects the project to succeed.
- 103. Scrum terminology (a) Scrumterm Definition Development team A self-organizing group of software developers, which should be no more than 7 people. They are responsible for developing the software and other essential project documents. Potentially shippable product increment The software increment that is delivered from a sprint. The idea is that this should be ‘potentially shippable’ which means that it is in a finished state and no further work, such as testing, is needed to incorporate it into the final product. In practice, this is not always achievable. Product backlog This is a list of ‘to-do’ items that the Scrum team must tackle. They may be feature definitions for the software, software requirements, user stories, or descriptions of supplementary tasks that are needed, such as architecture definition or user documentation. Product owner An individual (or possibly a small group) whose job is to identify product features or requirements, prioritize these for development and continuously review the product backlog to ensure that the project continues to meet critical business needs. The Product Owner can be a customer but might also be a product manager in a software company or other stakeholder representative.
- 104. Scrum terminology (b) Scrumterm Definition Scrum A daily meeting of the Scrum team that reviews progress and prioritizes work to be done that day. Ideally, this should be a short face-to-face meeting that includes the whole team. ScrumMaster The ScrumMaster is responsible for ensuring that the Scrum process is followed and guides the team in the effective use of Scrum. He or she is responsible for interfacing with the rest of the company and for ensuring that the Scrum Team is not diverted by outside interference. The Scrum developers are adamant that the ScrumMaster should not be thought of as a project manager. Others, however, may not always find it easy to see the difference. Sprint A development iteration. Sprints are usually 2-4 weeks long. Velocity An estimate of how much product backlog effort that a team can cover in a single sprint. Understanding a team’s velocity helps them estimate what can be covered in a sprint and provides a basis for measuring improving performance.
- 105. Quiz 2. According toAgile manifesto – A Individuals and interactions over people and technique B Individuals and interactions over projects and tools C Individuals and interactions over processes and tools. D Individuals and interactions over products and tools
- 106. Quiz Which of thefollowing is not an Agile methodology? A. Scrum B. PMBOK® 3 C. Crystal Clear D. Extreme programming (XP)
- 107. Quiz There are ...........phases in Scrum A. 2 B. 3 C. 4 D. 5
- 108. Quiz Which of thefollowing is responsible for sprint meeting? A. Scrum team B. Scrum master C. Product Owner D. None of the above
- 110. Kanban • The Japaneseword “kanban”, meaning “visual board” or a “sign”, has been used in the sense of a process definition since the 1950s. It was first developed and applied by Toyota as a scheduling system for just-in-time manufacturing. The approach represents a pull system. This means that production is based on customer demand rather than the standard push practice to produce goods and push them to the market. • Kanban is considered a “lean production” technique, or one that eliminates labor and inventory waste. • One of the ways Kanban reduces waste is through the “pull production” model that regulates item production based on consumer supply and demand.
- 111. Kanban • It isa large to-do list, which helps manage work according to priority. • A central principle of Kanban is that the tasks and their status are visualized as cards on a board, visible to all project staff. • In Kanban, when a developer, tester, or other team member is ready for more work, they pull a task on the board by moving it to “Doing” or a specific work status like “Testing”.
- 112. Stages of Kanban 1.VisualizeWork – define the process followed by the project team (for example, Not Started > Development > Dev Testing > Acceptance Testing > Done). Setup a board with a column for each process stage, and post the tasks on the board as sticky notes. 2.Limit Work in Progress (WIP) – a key principle of lean manufacturing, Kanban enforces a limit on the number of tasks the team works on concurrently – usually no more than 2-3. 3.Pull Don’t Push – each team member finishes their current task and then “pulls” an additional assignment from the board. This prevents bottlenecks when one part of the team has a higher throughput than another. 4.Monitor and Improve – visualizations like the cumulative flow chart below help understand how work is progressing and identify bottlenecks in the process.
- 113. 11 Kanban ● Kanban isan incremental process. It fulfills all the 12 different principles of agile methodologies. The main aspect of Kanban is the transparency in the software development cycle. Kanban boards and tools are used for project traceability. This board is used in a 3 step process: ❑To do ❑In Progress ❑Done ● To track any work in a project, the cards are used on the board to represent the state of every work. This gives a clear picture of the workflow and progress of a team.
- 114. The Kanban Methodology dependson various principles, such as: ❖ Visualize Work ❖ Limit Work in Progress ❖ Pulling New Work ❖ Measure and Learn ❖ Manage the Workflow ❖ Process improvement ❖ Working Together ❖ Deliver with new Ideas ❖ Just in Time Development ❖ Welcome to Incremental Change
- 116. Advantages Of KanbanMethodology ❖ It increases the Productivity of the team. ❖ It provides a flexibility and sustainable development. ❖ It deals with continous process improvement and delivery. ❖ Kanban methodology eradicates the bugs from the process. ❖ Increase the efficiency of deliver a high quality product. ❖ It depends on just in time development. ❖ It limits the work in progress, so enhance the output. ❖ It focuses on one task at time. ❖ It provides the status of project in Kanban Board, its open for all. ❖ It improves the workflow and limits the time cycle. ❖ It maintains workflow status, collaboration on the team and sustainable development.