CMSC 128 Notes Unit 1-3.pdf

UNIT 1: INTRODUCTION TO SOFTWARE ENGINEERING -Examples: E-commerce applications SOFTWARE Embedded control systems- control and manage hardware devices -Collection of computer programs, procedure rules, and asso...

UNIT 1: INTRODUCTION TO SOFTWARE ENGINEERING -Examples: E-commerce applications SOFTWARE Embedded control systems- control and manage hardware devices -Collection of computer programs, procedure rules, and associated -Examples: Mobile Applications, Anti-lock braking in a documentation and data car software -Comprised of source code, executables, design documents, Entertainment systems- for personal use and which are intended operations and system manuals, and installation and to entertain the user implementation manuals, or a subset of these -Examples: Games SOFTWARE COMPUTER PROGRAMS Systems for modeling and simulation- developed by scientists -Consists not only of the -Combination of source code and engineers to model physical processes or situations program code but also of and object code Data collection systems- collect data from their environment all the associated -Subset of software -Becomes using a set of sensors and send that data to other systems for documents: software only if processing > Requirements documentation and Systems of systems- composed of a number of other software specification operating procedure systems documents manuals are prepared -Examples: generic software products, such as a > Design documents spreadsheet program > Test documents SOFTWARE QUALITY & DESIRED ATTRIBUTE > User manuals -What makes a “good” software? > Operational manuals Software quality is concerned with: -Software behavior while executing -Structure and organization of system programs and WRITING A SOFTWARE WRITING A PROGRAM associated documentation -Developed by a team -Usually small Desired Attributes -Other people will use it -For yourself, usually -Specific set of attributes that you might expect from a -Other engineers will -No one else will use it but software system depends on its application change it you -Examples: Banking system must be secure, -Bigger than writing -No manuals and design Interactive game must be responsive, programs documents Critical systems must be reliable -Provide manuals, docs, -Limited functionality ESSENTIAL ATTRIBUTES OF GOOD SOFTWARE source code Maintainability -Systematic development -Software can evolve to meet the changing needs of -More functionality and customers better UI -A critical attribute because software change is inevitable SOFTWARE DEVELOPMENT VS PROGRAMMING Dependability and security Programming- Creating applications to perform a simple task -Includes reliability, security, and safety Software Development- Creating professional applications that are -Should not cause physical or economic damage in the easy to use, expandable, and easy to change event of system failure IMPORTANCE OF SOFTWARE -Malicious users should not be able to access or damage -Engine that drives business decision making the system -The basis for modern scientific investigation and should not make wasteful use of system resources such as engineering problem solving memory and processor cycles -Commerce, our culture, and our everyday activities responsiveness, processing time, memory utilization, etc -It is embedded in all kinds of systems, such as: Acceptability > Transportation > Medical -acceptable to the type of users for which it is designed > Telecommunications > Military -understandable, usable, and compatible with other > Industrial processes > Entertainment systems that they use > Office products GENERAL ISSUES OF SOFTWARE -It affects nearly every aspect of our lives Heterogeneity KINDS OF SOFTWARE PRODUCTS -Systems are required to operate across networks that Generic products- Stand-alone systems developed and sold to the include different types of computer and mobile devices open market to any customer who can buy them Business and social change -Examples: Databases, Word processors, Drawing -Business and society are changing incredibly quickly as packages, Project-management tools, emerging economies develop and new technologies Software for specific markets become available Customized (or bespoke) products-Commissioned by a particular -Need to be able to change their existing software and to customer to meet their required needs/functionalities rapidly develop new software -Examples: Control systems for electronic devices, Air Security and trust traffic control systems, Inventory Systems -As software is intertwined with all aspects of our lives PRODUCT SPECIFICATION -Essential that we can trust that software Generic Products- Software Developers controls the specification SOFTWARE DEVELOPMENT VS of what the software should do SOFTWARE ENGINEERING -Decisions on software change are made by the developer Software Development Customized Products- Customers controls the specification of - the heart of software engineering what the software should do -The process of: -Customers make the decisions on software changes > Taking a set of requirements from a user APPLICATION TYPES (problem statement) Stand-alone applications- run on a local computer, such as a PC > Analyzing the requirements -include all necessary functionality and do not need to be > Designing a solution to the problem connected to a network > Implementing the solution on a computer -Examples: office applications on a PC, CAD programs, Software Engineering photo manipulation software -Involves a process and includes software development Interactive transaction-based Applications- execute on a remote -Also includes: project management, configuration computer and that are accessed by users from their own PCs or management, scheduling and estimation, terminals baseline building and scheduling,  managing people -Engineering discipline: SOFTWARE PROCESS ACTIVITIES > Using appropriate theories and methods to solve Software specification problems -customers and engineers define the software that is to be > Always bearing in mind organizational and financial produced and the constraints on its operation constraints Software development -All aspects of software production (not only technical -where the software is designed and programmed process of development) Software validation -Includes the following to support software production: -software is checked to ensure that it is what the Project management, Development of tools, Methods customer requires -It is a systematic approach to the production of software Software evolution that takes into account: Practical cost, Schedule, -software is modified to reflect changing customer and Dependability issues, Needs of market requirements software customers and producers MAJOR CONCERNS FOR SOFTWARE PROJECT IMPORTANCE OF SOFTWARE ENGINEERING - How long will it take? -Individuals and society rely on advanced software systems - How much will it cost? more and more LEARNING SOFTWARE DEVELOPMENT -It is usually cheaper in the long run to use software -Reading excellent designs engineering methods for software systems rather than just -Reading a lot of code write programs. -Writing a lot of code -Thinking deeply about how you approach a problem and SOFTWARE COMPUTER SCIENCE design a solution for it ENGINEERING focuses on theory and HOW CAN WE DEVELOP SOFTWARE? concerned with practicalities fundamentals -A small, well integrated team of developing and delivering -Good communication among team members useful software -Good communication between the team and the customer -The ability to be flexible about that process - includes software SOFTWARE -A plan that everyone buys into development, but it also DEVELOPMENT SOFTWARE DIVERSITY includes the entire management the fun part of software -How systematic and organized approach is implemented side of creating software engineering varies on: - includes project management, > organization developing the software scheduling and estimation, > type of software managing people, among others > people involved in development process -Engineering is about selecting the most appropriate method for a set of circumstances so a more creative less formal approach to development may be effective in some - Delays and incomplete details HARDWARE circumstances in software designs are DEVELOPMENT -There are many different types of software system and relatively acceptable and - It is a requirement for there is no universal set of software techniques that is sometimes even encouraged ( hardware designs to be applicable to all of these in some Agile methodologies) completed before they can be -Different types of software require different approaches - If there is a bug in software, manufactured and shipped -There is no silver bullet for software development just wait for the upgrade, - If there is a bug in hardware, BEST TECHNIQUES AND METHODS bugfix or patch they are returned to the -No method is better than another, just more appropriate - Software upgrades are manufacturer (lose money if a -Games should be developed using a series of prototypes relatively cheap, even free. lot is returned) -Safety critical control systems require a complete and (gives you a little room for - Hardware upgrades are very analyzable specification to be developed error) costly. (no room for error) SOFTWARE CRISIS - Software products can be - Hardware products are Problems continuously improved independent products. -Schedule and cost estimates are often grossly inaccurate - Software is long-lasting - Hardware decays -"Productivity" of software people hasn't kept pace with the demand for their services -Quality of software is sometimes less than adequate part of this more general SYSTEM ENGINEERING -Communication between customer and software process (system engineering) concerned with all aspects of developer is often poor computer-based systems Causes development including -If there's delay in any process or stage, then scheduling hardware, software and process doesn't match with actual timing engineering -Miscommunication between managers, customers, ASPECTS OF SOFTWARE ENGINEERING software developers, support staff -Processes necessary to turn a concept into a robust Programmer’s Problems User’s Problems deliverable that can evolve over time -Working with limited time and resources -Satisfying a customer -Documentation -Software cost is very high -Managing risk -Coordination of Work of -Different versions of -Teamwork and communication different people software FUNDAMENTAL PRINCIPLES -User interface -Fundamental principles that apply to all types of software -Bugs system, regardless of development techniques used: SOFTWARE ENGINEERING > Systems should be developed using a managed and -An engineering discipline that is concerned with all aspects understood development process (different depending of software production: from the early stages of system on type of software) specification to maintaining the system after it has gone > Dependability and performance are important for all into use. types of system -Understanding and managing the software specification and -Cloud Computing provides computing resources that are not tied requirements (what software should do) are important to any specific location. -Where appropriate, you should reuse software that has -Cloud basically consists of: Virtual computers/servers, Data already been developed rather than write new software storage capacity. Communications and messaging capacity., WEB AS A PLATFORM Network capacity, Development environments -The Web is now a platform for running application -In other words, Cloud Computing is for software developers, -Organizations are increasingly developing web-based application vendors, savvy computer users, and corporate IT systems rather than local systems departments, not for people who use computer applications -Web services allow application functionality to be accessed SOFTWARE ENGINEERING ETHICS over the web -Software engineering involves wider responsibilities than simply WEB SOFTWARE ENGINEERING the application of technical skills -Software reuse is the dominant approach for constructing -Software engineers must behave in an honest and ethically web-based systems responsible way if they are to be respected as professionals -When building web-based systems, you think about how -Ethical behavior is more than simply upholding the law but you can assemble them from pre-existing software involves following a set of principles that are morally correct components and systems ISSUES OF PROFESSIONAL RESPONSIBILITY -Web-based systems should be developed and delivered Confidentiality- Engineers should respect the confidentiality of incrementally their clients regardless of whether a formal confidentiality -It is now generally recognized that it is impractical to agreement has been signed or not specify all the requirements for a web-based system in Competence- Engineers should not misrepresent their level of advance competence -User interfaces are constrained by the capabilities of web -They should not knowingly accept work which is not within browsers their capabilities -Web forms are commonly used Intellectual property rights- Engineers should be aware of local -Technologies such as Ajax allow rich interfaces to be laws governing use of intellectual property such as patents, created within a web browser copyrights, etc. -Web-based systems are complex distributed systems, but -Be careful to ensure that the intellectual property of client is fundamental ideas and principles of SE are applicable as protected well Computer misuse- Engineers should not use their technical skills CLOUD COMPUTING to misuse other people’s computers -It is the use of hardware / software that are delivered as a -Computer misuse can be trivial (playing games on employer's service over a network (typically the Internet) machine) or serious (dissemination of virus) -An approach to the provision of computer services where applications run remotely on the "cloud" UNIT 2: SOFTWARE PROCESSES - End users access cloud-based applications through a web SOFTWARE PROCESSES browser or a light-weight desktop or mobile app while the -A set of related activities that leads to the production of a software business software and user's data are stored on servers at a product remote location. -May involve development of software from scratch or by -Name comes from the use of a cloud-shaped symbol as an extending and modifying existing systems or by configuring and abstraction for the complex infrastructure it contains in integrating off-the-shelf software components system diagrams -Many different software processes but all involve: -Users do not buy software but pay according to use. Software specification- defining the requirements of the -Usually, software is free and have advertisements to system(what the software should do) generate income Software design and implementation- defining the SOFTWARE AS A SERVICE (SaaS) organization of the system and implementing the system -A software delivery model in which software and Validation- checking that software does what the customer associated data are centrally hosted in the cloud. wants -Traditional software: binary code installed and runs on Evolution- changing the system in response to changing client’s machine customer needs -SaaS delivers software and data as a service over the -We usually talk about the activities in these processes Internet via a thin program (e.g., browser) running on -Software process descriptions may also include: client device Products-outcomes of a process activity -Examples: search, social networking, video streaming -Examples: model of the software architecture BENEFITS OF SaaS Roles- reflect the responsibilities of the people involved in the -No install worries about hardware and OS capability process -No worries about data loss (at remote site) -Examples: project manager, configuration manager, -Easy for groups to interact with same data programmer -If data is large or changed frequently, it is simpler to keep Pre-and Post-conditions- statements that are true before and -1 copy at the central site. 1 copy of software + controlled after a process activity has been enacted or a product hardware environment = No compatibility hassles for produced developers -Examples: Pre-condition: may be that all requirements have -1 copy = simplifies upgrades for developers been approved by the customer; Post-condition: UML DEMANDS ON INFRASTRUCTURE models describing the architecture have been reviewed Communication -Allow customers to interact with the service -In practice, most practical processes include elements of both Dependability- Service and communication continuously plan-driven and agile approaches available 24/7 -There are no right or wrong software processes Scalability- Must be able to respond well to increase in demand PLAN-DRIVEN PROCESS of service -all of the process activities are planned in advance SaaS VS CLOUD -progress is measured against this plan -When you run a SaaS application, you login to your vendor’s AGILE PROCESSES website -planning is incremental -SaaS applications are running on the cloud but not the cloud. -easier to change the process to reflect changing customer CLOUD COMPUTING requirements SOFTWARE PROCESS MODELS -Simplified representation of a software process Development and integration - Software that can't be procured is -It presents a description of a process from some particular developed perspective -Components and COTS are integrated to create new system WATERFALL MODEL TYPES OF SYSTEM COMPONENTS -Separate and distinct phases of specification and development Web services -There are separate identified phases in the waterfall model: Framework Packages (e.g. laravel, cakephp) Requirements analysis and definition Stand-alone software systems (COTS) configured for use in a -Specifies what the system should do particular environment System and software design BENEFITS OF REUSE-ORIENTED SE -Establishing an overall system architecture -Reduced amount of software to be developed -Involves identifying and describing the fundamental software -Reduced amount of cost and risk system abstractions and their relationships -Leads to fast delivery of software Implementation and unit testing PROBLEMS OF REUSE-ORIENTED SE -Design is implemented as a set of programs or program units -Usually there's no exact match for components needed but only -Unit testing involves verifying that each unit meets the required provide some of the functionality required needs -Requirements compromises are inevitable and may lead to system Integration and system testing that doesn't meet real needs of users -The individual program units or programs are integrated and -Control over system evolution is lost as new versions of reusable tested as a complete system component are not under the control of organization using them Operation and maintenance PROCESS ACTIVITIES -Maintenance involves correcting errors which were not -Real software processes are sequences of technical, collaborative discovered in earlier stages of the life cycle and managerial activities with the overall goal of specifying, -System improvement designing, implementing and testing a software system -The product of each phase is a document that is signed off or -The four basic process activities are organized differently in approved. different development processes. - In principle, a phase must be complete before moving onto the For the waterfall model - organized in sequence next phase. For Incremental development - delivered by increments -The main drawback of the waterfall model is the difficulty of SOFTWARE SPECIFICATION accommodating change after the process is underway -The process of establishing what services are required as well as -Few business systems have stable requirements. the constraints on the system’s operation and development. -Mostly used for large systems engineering projects where a -Includes the requirements engineering process system is developed at several sites. REQUIREMENTS ENGINEERING PROCESS -In those circumstances, the plan-driven nature of the waterfall Feasibility study model helps coordinate the work -Is it technically and financially feasible to build the system? WATERFALL VS CHANGE Requirements elicitation and analysis -During design, requirement problems might be discovered -What do the system stakeholders require or expect from the -During coding, design problems might be discovered system? -Go back and modify documents to reflect changes Requirements specification -Problems are sometimes left for later resolution, ignored, or -Defining the requirements in detail programmed around ("patch") Requirements validation BENEFITS OF THE WATERFALL MODEL -Checking the validity of the requirements -Models and documents are produced at each phase -Usually a continuous process PROBLEMS OF THE WATERFALL MODEL -Starts at early stage of project -Inflexible partitioning of the project into distinct stages makes it -As new requirements come to light, requirements engineering is difficult to respond to changing customer requirements revisited INCREMENTAL DEVELOPMENT SOFTWARE DESIGN AND IMPLEMENTATION -Specification, development and validation are interleaved -The process of converting the system specification into an -First, develop the core software (Release 1) executable system. -Additional functionality and supplemental features are then -The activities of design and implementation are closely related developed (Release 2) and may be interleaved BENEFITS OF INCREMENTAL DEVELOPMENT DESIGN ACTIVITIES -The cost of accommodating changing customer requirements is Architectural design- Identify the overall structure of the system, reduced. the principal components, their relationships and how they are -It is easier to get customer feedback on the development work that distributed has been done. Interface design- define the interfaces between system -More rapid delivery and deployment of useful software to the components. customer is possible Component design- take each system component and design how PROBLEMS OF INCREMENTAL DEVELOPMENT it will operate. -The process is not visible Database design- where you design the system data structures and -System structure tends to degrade as new increments are added how these are to be represented in a database REUSE-ORIENTED SOFTWARE ENGINEERING SOFTWARE VERIFICATION AND VALIDATION (V&V) -Based on systematic reuse where systems are integrated from -Intended to show that a system conforms to its specification and existing components or COTS (Commercial-off-the shelf) systems meets the requirements of the system customer. -Reuse is now the standard approach for building many types of -Involves checking and review processes and system testing business system STAGES OF TESTING REUSE-ORIENTED SE PROCESS STAGE Development or Component testing Component analysis - Given requirements specification, search - Individual components are tested independently; for components to implement that specification -Components may be functions or objects or coherent groupings Requirements modification - Requirements are analyzed and of these entities. modified using information about components to reflect available System Testing components -Testing of the system as a whole System design with reuse - Framework of system is designed, or -Testing of emergent properties is particularly important existing framework is reused Acceptance testing -Designers consider components that are reused -Testing with customer data to check that the system meets the  customer’s needs -Some projects use the prototypes as basis for the final software TYPES OF TESTING and build on top of it Alpha Testing INCREMENTAL DELIVERY -Used in custom systems developed for a single client Development and delivery are -Testing process continues until system developers and client -each increment delivers some required functionality agree that delivered system is acceptable (acceptance testing) Prioritized user requirements -Alpha testing is for customized software products -Highest priority ones included in early increments Beta Testing Requirement changes -Used when system is to be marketed as a software product -Once the development of an increment is started, requirements -Deliver system to some potential customer who agrees to use for later increments continue to evolve the system (beta testers) INCREMENTAL DEVELOPMENT AND DELIVERY -Beta testers report problems to developer, exposing the Incremental Development product to real users and detecting errors that may not have -Develop the system in increments and evaluate each increment been anticipated by developers before proceeding to the development of the next increment -Beta testing is for generic software products -Normal approach used in agile methods SOFTWARE EVOLUTION -Evaluation done by user/customer proxy - Software is inherently flexible and can change -Deploy an increment for use by end-users COPING WITH CHANGE -More realistic evaluation about practical use of software -Change is inevitable in all large software projects. -Difficult to implement for replacement systems as increments -New technologies open up new possibilities for improving have less functionality than the system being replaced implementations ADVANTAGES OF INCREMENTAL DELIVERY -Changing platforms require application changes -Customer value can be delivered with each increment, so system REWORK functionality is available earlier. -Change leads to rework so the costs of change include: -Early increments act as a prototype to help elicit requirements for Rework (e.g., re-analyzing requirements) later increments Implementing new functionality -The highest priority system services tend to receive the most -Reducing Rework Cost testing Change Avoidance -Lower risk of overall project failure Change Tolerance PROBLEMS OF INCREMENTAL DELIVERY REDUCING REWORK COST -Most systems require a set of basic facilities that are used by Change Avoidance different parts of the system. -Software process includes activities that can anticipate possible -As requirements are not defined in detail until an increment is to changes before significant rework is required be implemented, it can be hard to identify common facilities that -Change avoidance anticipates possible changes before are needed by all increments. significant rework is required. -When replacement systems are developed, users want all the Change Tolerance functionalities of the old system. -Process is designed so that changes can be accommodated at -They might not want to experiment with an incomplete new relatively low cost system -Changes may be in a future increment (no rework) or may have BOEHM’S SPIRAL MODEL to alter part of the existing system -Developed by Barry Boehm -Change tolerance accommodates changes at relatively low cost -Process is represented as a spiral rather than as a sequence of EXAMPLES OF WAYS TO COPE UP WITH CHANGE activities with backtracking. Software Prototyping (avoidance) -Each loop in the spiral represents a phase in the process. Incremental Delivery (avoidance & tolerance) -No fixed phases such as specification or design Boehm's Spiral Model (avoidance & tolerance) -Main Feature: Risks are explicitly assessed and resolved SOFTWARE PROTOTYPING throughout the process -A prototype is an initial version of a system used to demonstrate SPIRAL MODEL SECTOR concepts and try out design options. Objective setting -A prototype can be used in: -Specific objectives for the phase are identified. The requirements engineering process to help with Risk assessment and reduction requirements elicitation and validation -Risks are assessed and activities put in place to reduce the key In design processes to explore options and develop a UI design risks In the testing process to run back-to-back tests Development and validation- Choose development model PROTOTYPE DEVELOPMENT PROCESS Planning-The project is reviewed and the next phase of the spiral -Focus on functional rather than nonfunctional requirements such is planned as reliability and security SPIRAL MODEL STRENGTHS -Error checking and recovery may not be included in the prototype -Combines change avoidance and change tolerance PROTOTYPES -Assumes that changes are results of project risks, so it includes -Don't necessarily need to be executable files explicit risk management activities to reduce risks -They can also be paper-based mockups of user interface -Strong approval and documentation control -Mockup software can help with prototyping (e.g., Balsamiq, -Additional functionality can be added at a later date Figma) SPIRAL MODEL BENEFITS OF PROTOTYPES -Development model might vary for each loop -Improved system usability SPIRAL MODEL WEAKNESSES -A closer match to users' real needs -Time spent evaluating risks too large for small or low-risk projects -Improved design quality -Time spent planning, resetting objectives, doing risk analysis and -Improved maintainability prototyping may be excessive -Reduced development effort -The model is complex THROW-AWAY PROTOTYPES WHEN TO USE SPIRAL MODEL -Prototypes should be discarded after development as they are not a -When creation of a prototype is appropriate good basis for a production system -When costs and risk evaluation is important -It may be impossible to tune the system to meet non-functional -For medium to high-risks projects requirements RATIONAL UNIFIED PROCESS (RUP) -Prototypes are normally undocumented -A modern generic process derived from the work on the UML and  associated process. -Individuals and interactions over processes and tools -Brings together aspects of the 3 generic process models discussed -Working software over comprehensive documentation previously (waterfall, incremental, reuse-oriented) -Customer collaboration over contract negotiation -Not suitable for all types of development -Responding to change over following a plan -Most important innovation: separation of phases and workflows & PRINCIPLES OF AGILE METHODS recognizing that deploying software is part of the process Customer involvement -Phases: Dynamic and have goals -Provide and prioritize new system requirements -Workflows: static and technical activities not associated with a -Evaluate the iterations of the system single phase; may be used throughout development to achieve Incremental Delivery goals of each phase -Developed in increments with the customer RUP PERSPECTIVE People not process -RUP is normally described from 3 perspectives: -Team members work without prescriptive process A dynamic perspective that shows phases over time Embrace change A static perspective that shows process activities Maintain simplicity A practice perspective that suggests good practice -Eliminate complexity from the system RUP PHASES AGILE METHOD APPLICABILITY Inception - Project scope, extent and business case are defined -Custom system development within an organization where: Elaboration - Project planning, feature specification, baseline Clear commitment from the customer architecture Not a lot of external rules and regulations Construction -Construction of the product -Product development where a software company is developing a Transition - Product is taken into use small or medium-sized product for sale. RUP GOOD PRACTICE -Because of their focus on small, tightly integrated teams, there are -Develop software iteratively. problems in scaling agile methods to large systems -Manage requirements THINGS TO CONSIDER -Use component-based architectures Customer interests -Visually model software Team members intense involvement -Verify software quality Multiple stakeholders -Control changes to software PROBLEMS -Maintaining simplicity requires extra work UNIT 3: AGILE SOFTWARE DEVELOPMENT -Large organizations difficulty in following an informal devt BUSINESS ENVIRONMENT AGILE METHODS AND SOFTWARE MAINTENANCE -Rapid development and delivery is now often the most important -More maintenance on existing software than on new software requirement for software systems development -Software must evolve quickly to reflect changing business needs -So, if agile methods are to be successful, they must support -Software development processes that plan on completely maintenance as well as original development specifying requirements and design are not geared for rapid -Problems may arise if original development team cannot be development and delivery maintained -Significant rework and retesting will be done once changes are KEY ISSUES made later Are systems that are developed using an agile approach RAPID SOFTWARE DEVELOPMENT maintainable? -Specification, design and implementation are interleaved -Formal documentation is supposed to describe the system to -System is developed as a series of versions with stakeholders make it easier to understand for people changing the system involved in version evaluation -Not up to date -User interfaces are often developed using an IDE and graphical -Don’t accurately reflect what’s in the actual source code toolset -Waste of time HISTORY -System requirements document is essential. Does agile not -In the 80s and early 90s, dominant view was : "to achieve better create this document? software quality, it must undergo careful planning, analysis and -Agile collects requirements informally and incrementally design“ Can agile methods be used effectively for evolving a system in -This was true and useful for teams that developed large, long lived response to customer change requests? systems -It is likely to be effective -Large teams worked for different companies, and they were PLAN-DRIVEN AND AGILE geographically dispersed -Plan-driven development -Planning approach involves significant overhead in planning, Separate development stages designing and documenting the system Not necessary waterfall model; plan-driven, -Doesn't apply well to small & medium-sized business systems incremental development is possible -More time is needed for development and testing, rather than Iteration occurs within activities planning, analysing and designing -Agile Development -Requirements change frequently = rework, re-analyzing Specification, design, implementation and testing are specifications, redesign interleaved AGILE METHODS The outputs from the development process are decided -Dissatisfaction with the overheads involved in software design through a process of negotiation during the software methods of the 1980s and 1990s led to the creation of agile development process methods. AGILE SPECIFICATION -Focus on the code rather than the design -Agile is not inevitably code-focused only -Are based on an iterative approach to software development -Might produce some design documentation during a -Are intended to deliver working software quickly and evolve this documentation spike quickly to meet changing requirements TECHNICAL, HUMAN, ORGANIZATIONAL ISSUES AIM OF AGILE METHODS -Most projects include elements of plan-driven and agile processes. -Reduce overheads in the software process (e.g., by limiting Deciding on the balance depends on the ff: documentation) Technical Issues -Respond quickly to changing requirements without excessive -Is it important to have a very detailed specification and rework design before moving to implementation? AGILE MANIFESTO -Is an incremental delivery strategy realistic?  -How large is the system that is being developed? XP AND CHANGE -What type of system is being developed? -XP, however, maintains that this is not worthwhile as changes > Plan-driven approaches may be required for systems cannot be reliably anticipated. that require a lot of analysis before implementation -Rather, it proposes constant code improvement (refactoring) to -What is the expected system lifetime? make changes easier when they have to be implemented > Long-lifetime systems may require more design REFACTORING documentation to communicate the original intentions -Programming team looks for possible software improvements of the system developers to the support team -Improves the understandability of the software -What technologies are available to support system -Changes are easier to make development? -However, some changes requires architecture refactoring > Agile methods rely on good tools to keep track of an -Examples: evolving design Re-organization of a class hierarchy -Is the system subject to external regulation? Tidying up and renaming attributes and methods > If a system must be approved by an external regulator Replacement of inline code with calls to methods (e.g., aircraft operation) then you will probably be XP IN PRACTICE required to produce detailed documentation as part of -In practice, many companies have adapted extreme programming the system safety case but don’t use all XP practices Organizational Issues -Pair Programming vs. individual programming -How is the development team organized? -Small releases, TDD, continuous integration > If the development team is distributed or if part of the TESTING IN XP development is being outsourced, then you may need to -XP follows an incremental approach develop design documents to communicate across the -Testing is central to XP development teams -Program is tested after every change has been made -Are there cultural or organizational issues that may affect XP TESTING FEATURES the system development? Test-Driven development > Traditional engineering organizations have a culture of Incremental test development from scenarios. plan-based development, as this is the norm in User involvement in test development and validation. engineering Automated test harnesses are used to run all component tests each Human Issues time that a new release is built -How good are the designers and programmers in the TEST-DRIVEN DEVELOPMENT development team? -Tests are written as programs rather than data so that they can be >It is sometimes argued that agile methods require higher executed automatically. skill levels than plan-based approaches in which -Run the test as code is being written programmers simply translate a detailed design into -The test includes a check that it has executed correctly. code -Writing tests before code clarifies the requirements to be EXTREME PROGRAMMING implemented -Perhaps the best-known and most widely used agile method -Ambiguity and omission in spec must be clarified first before -Developed by Kent Beck, 1999 implementation -Extreme Programming (XP) takes an ‘extreme’ approach to -All previous and new tests are run automatically when new iterative development functionality is added -New versions may be built several times per day. -Avoids the problem of test lag -Increments are delivered to customers every 2 weeks. -Test-Driven Development (TDD) is also known as Test-first -All tests must be run for every build and the build is only accepted Development if tests run successfully -"Test-first" technique to develop and design software EXTREME INCREMENTAL DEVELOPMENT -Introduced to the community by Kent Beck in 2002 -Release deadlines are never slipped TEST LAG -If problems exist, customer is consulted, and functionality is -It is when the developer is faster than the tester removed from planned release -Implementation gets farther ahead of development -When changing a new version, run all existing automated tests -Sometimes, tests are skipped to maintain development schedule first to make sure you didn't break anything (Regression testing) CUSTOMER INVOLVEMENT -Build is accepted only when all tests pass -Develop acceptance tests XP AND AGILE PRINCIPLES -The customer who is part of the team writes tests as development Incremental Development proceeds. Customer Involvement -All new code is therefore validated People not process ACCEPTANCE TEST Change supported through regular system releases. -The process where the system is tested using actual customer data Maintaining simplicity through constant refactoring of code -This is done before the developer turns over the system to the XP PRACTICES customer ("acceptance") Incremental Planning Small Releases TEST AUTOMATION Simple Design Test-first Development -Test automation means that tests are written as executable Refactoring Pair Programming components before the task is implemented Collective Ownership Continuous integration -These testing components should be: Sustainable pace On-site customer standalone REQUIREMENTS SCENARIOS simulate the submission of input to be tested -In XP, a customer or user is part of the XP team and is responsible check that the result meets the output specification. for making decisions on requirements. -An automated test framework (e.g. JUnit, PHPUnit, JSUnit) is a -User requirements are expressed as scenarios or user stories. system that makes it easy to write executable tests and submit a -Written on cards and the development team break them down into set of tests for execution implementation tasks -As testing is automated, there is always a set of tests that can be -These tasks are the basis of schedule and cost estimates. quickly and easily executed -The customer chooses the stories for inclusion in the next release -Whenever any functionality is added to the system, the tests can based on their priorities and the schedule estimates be run and problems that the new code has introduced can be USER STORIES caught immediately. Design for change Anticipating changes -Although TDD and automated testing results in a large number of  tests being written and executed, it doesn't necessarily lead to a of technical, functional or other specialty. thorough program testing [Why?] Stakeholder - A person external to the Scrum Team with a -Test cases are only as good as your understanding of the specific interest in and knowledge of a product that is required specification for incremental discovery. Represented by the Product Owner -If you didn't understand a requirement, you might fail to include and actively engaged with the Scrum Team at Sprint Review some key test cases regarding that requirement Product Backlog - A Scrum Artifact that consists of an ordered XP TESTING DIFFICULTIES list of the work to be done to create, maintain and sustain a -Programmers prefer programming to testing and sometimes they product. Managed by the Product Owner. take short cuts when writing tests. Product Goal - The Product Goal describes a future state of the -Some tests can be very difficult to write incrementally. product which can serve as a target for the Scrum Team to plan -It is difficult to judge the completeness of a set of tests against. The Product Goal is in the Product Backlog. The rest of PAIR PROGRAMMING the Product Backlog emerges to define “what” will fulfill the -In XP, programmers work in pairs, sitting together to develop Product Goal. code. Sprint - Takes about 2-4 weeks, that serves as a container for the -This helps develop common ownership of code and spreads other Scrum events and activities. Sprints are done knowledge across the team consecutively, without intermediate gaps -The “pair” in Pair Programming includes: Scrum Board - A physical board to visualize information for and Driver- writes the code by the Scrum Team, often used to manage Sprint Backlog. Navigator/Observer- reviews each line of code as it is typed in Scrum boards are an optional implementation within Scrum to -It serves as an informal review process as each line of code is make information visible. looked at by more than 1 person. Sprint Backlog - Scrum Artifact that provides an overview of the -It encourages refactoring as the whole team can benefit from this development work to realize a Sprint’s goal, typically a forecast -Pairs are created dynamically so that all team members work with of functionality and the work needed to deliver that each other during the development process. functionality. Managed by the Developers. -The two programmers switch roles frequently. Sprint Goal - A short expression of the purpose of a Sprint, often -Measurements suggest that development productivity with pair a business problem that is addressed. Functionality might be programming is similar to that of two people working adjusted during the Sprint to achieve the Sprint Goal independently -A user story is an informal, general explanation of a software ADVANTAGES OF PAIR PROGRAMMING feature written from the perspective of the end user. Its purpose -It supports the idea of collective ownership and responsibility for is to articulate how a software feature will provide value to the the system. customer. User stories are used in the Product and Sprint -Individuals are not held responsible for problems with the code Backlogs to define your product’s proposed features. PROJECT MANAGEMENT -Creating a User Story: -The principal responsibility of software project managers is to As a (persona/role), I want (feature/task), so that (purpose/benefit) manage the project so that the software is delivered on time and Sprint Planning - Takes about 2-8 hours to start a Sprint. It serves within the planned budget for the project. for the Scrum Team to inspect the work from the Product -The standard approach to project management is plan-driven Backlog that’s most valuable to be done next and design that PLAN-DRIVEN PROJECT MANAGEMENT work into the Sprint backlog. -Managers draw up a plan for the project showing Sprint Review - Takes about 1-4 hours to conclude the what should be delivered development work of a Sprint. It serves for the Scrum Team and when it should be delivered the stakeholders to inspect the Increment of product resulting who will work on the development of the project from the Sprint, assess the impact of the work performed on deliverables. overall progress toward the Product Goal and update the Product -Manager has a stable view of everything that has to be developed backlog to maximize the value of the next period. and the development process Sprint Retrospective - Takes about 1-3 hours to end a Sprint. It AGILE PROJECT MANAGEMENT serves for the Scrum Team to inspect the past Sprint and plan for -Agile project management requires a different approach, which is improvements to be enacted during future Sprints adapted to incremental development and the particular strengths Daily Scrum - Takes about 5-15 minutes. The Daily Scrum is held of agile methods every day of the Sprint where the developers plans work for the SCRUM next 24 hours. This optimizes team collaboration and -Scrum is a general agile method, but its focus is on managing performance by inspecting the work since the last Daily Scrum iterative development rather than specific agile practices. and forecasting upcoming Sprint work. The Daily Scrum is held -Developed by Ken Schwaber and Mike Beedle at the same time and place each day to reduce complexity. -Term derived from Rugby team's short huddle before the start of a “Let’s begin the scrum meeting..” play “This is what I have done last meeting..” THREE PHASES OF SCRUM “These are the obstacles I have encountered..” Initial phase - outline planning phase “This I what I plan to do today..” Series of Sprint Cycles - each cycle develops an increment of the “Does anyone have a solution to the problem?” system THE SPRINT CYCLE -go through the Assess-Select-Develop-Review phases -Scrum's major innovation Project Closure - wraps up the project -Sprints are of fixed length, normally 2–4 weeks. -completes required documentation such as system help frames -They correspond to the development of a release of the system in and user manuals XP. -assesses the lessons learned from the project -Assess-Select-Develop-Review phases THE SCRUM PROCESS -The starting point for planning is the product backlog, which is the Product Owner -The one accountable for maximizing the value of list of work to be done on the project a product, primarily by incrementally managing and expressing Assess phase: priorities are assigned to items with help from business and functional expectations for a product to the customer, who may also introduce new requirements developers Selection phase: involves the entire project team who work with Scrum Master - accountable for guiding, coaching, teaching and the customer to select the features and functionality to be assisting a Scrum Team and its environments in a proper developed during the sprint. understanding and use of Scrum. Develop phase: Once the features and functionality to be Developer - Any member of a Scrum Team, that is committed to developed are agreed, the team members organize themselves to creating any aspect of a usable Increment each Sprint regardless develop the software. The team is isolated from the customer  and the organization, with all communications channeled through the so-called "Scrum master" -The role of the Scrum master is to protect the development team from external distractions. During development, the way work is done depends on the team and the problem. Scrum doesn't make specific suggestions on how to write requirements, how to develop, etc. -XP practices can be used if the team thinks they are appropriate -Review phase: At the end of the sprint, the work done is reviewed and presented to stakeholders. -The next sprint cycle then begins 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 communicates with customers and management outside of the team. The whole team should be empowered to make decisions in Scrum -The whole team attends short daily meetings (stand-up) 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 SCRUM BENEFITS -The product is broken down into a set of manageable and understandable chunks. -Unstable requirements do not hold up progress. -The whole team have 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