SOFT2412 Exam Preparation PDF

lOMoARcPSD|22962037 SOFT2412 exam preparation Agile software Development Practices (University of Sydney) Scan to open on Studocu Studocu is not sponsored or endorsed by any college or university Downloaded by Eddie Wang (zixuanwan...

lOMoARcPSD|22962037 SOFT2412 exam preparation Agile software Development Practices (University of Sydney) Scan to open on Studocu Studocu is not sponsored or endorsed by any college or university Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 1 Software Development Process Models The Software Process Set of activities required to develop a software Activities are to be done, and in what order Lifecycle for a Software Development project Processes, a set of tools, definitions of the Artifacts, etc Many different development processes, but all includes common activities: o Specification (software/ system requirements) o Design and implementation o Validation (testing) o Evolution Software process are complex and rely on people’s decisions and judgement Activities are complex and include sub-activities o E.g. requirements validation, architectural design, unit testing Software Process Models Software Development Lifecycle (SDLC) Description of a process from particular perspective o Describe the activities and their sequence but may not the roles of people Representative Software Process Models Waterfall Model o Development process activities as process phases Spiral Model o Incremental development risk-driven Agile Model o Iterative incremental process for rapid software development The Rational Unified Process (RUP or UP) o Bring together elements of different process models o Phases of the model in timer, process activities, good practices Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 Waterfall Model: Heavy-Weight Model Development activities Teams Divide the work into stages A separate team of specialists for each stage At each stage, the work is passed Some coordination is required for the handoff from from one team to another team to team – using “documents” At the end of all of the stages, a As each team finished, they are assigned to a new software product ready to ship product Phases: o Requirements analysis and definition: requirements doc o System and software design: design document based on requirements doc o Implementation and unit testing: code and test it for system components (using design doc.) o Integration and system testing: software components are integrated, and the resulting system is tested o Operation and maintenance Advantages: o Intensive documenting and planning o Easy to understand and implement o Identified deliverables and milestones o Discovering issues in earlier phases should lead to returning to earlier phase Problems: o Difficulty of accommodating change after the process is underway o Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements o Mostly used for large systems engineering projects where a system is developed at several sites ⇒ The plan-driven nature of the waterfall model helps coordinate the work Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 Requirements Engineering Process Planning in Software Development Plan-driven (plan-and-document/ heavy-weight) o Activities are planned in advance and progress is measured against this plan o Plan drives everything and change is expensive Agile processes (light-weight) o Planning is incremental and continuous as the software is developed o Easier to change to reflect changing requirements Most SW processes include elements of both plan-driven and agile Each approach is suitable for different types of software Software Evolution Software is inherently flexible and can change As requirements change through changing business circumstances, the software that supports the business must also evolve and change Business software needs to respond to rapidly changing market o Time-to-market Plan-driven software development [processes are not suitable for certain types of SW systems Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 Rational Unified Process (RUP or UP) Software Development process utilizing iterative and risk-driven approach to develop OO software systems Iterative incremental development Iterative evolutionary development UP Phases and Disciplines Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 Agile Development Model Project Failure – the trigger for agility o One of the primary causes of project failure was the extended period of time it took to develop a system o Costs escalated and requirements changed o Agile methods intend to develop systems more quickly with limited time spent on analysis and design Agile Process Agile advocated believe: o Current SW development processes are too heavy=wright or cumbersome o Current software development is too rigid ⇒ Incomplete or changing requirement o More active customer involvement needed Agile methods are considered o Light weight o People-based rather than plan-based Several agile methods o No single agile method o Extreme Programming (XP), Scrum Agile Manifesto closes to a definition o Set of principles o Developed by Agile Alliance Agile Principles Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 Software (Development) Process Models Agile – Requirements Process There is no “standard way” to do requirements in Agile development o Could be a normal “Software Requirements Document”, but more lightweight o Based on user stories o In each iteration, elaborate a small set of the functional requirements (the high-priority behaviour) o For some key requirements, create some acceptance tests at the same time as you write the requirements Documentation o Still important in an Agile development o If it is the only kind of communication in your project, it isn’t good o Real working code is more valuable than documents Development plans o Still important in an Agile development o The format of an Agile development schedule is a bit different o Development plan includes “iterations” o Each iteration gives the team to chance to incorporate what they learn Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 2 Tools and Technologies for Controlling Artifacts Software Artifact – Software Requirements Specifications Different formats in various process methodologies o In agile, often as “User stories” (plain text, stylized format, can be manipulated by tools) o In traditional methodologies, often huge Word documents in a standard template ⇒ Software Requirements Specification (SRS) ⇒ Signed off as obligation on the developers Track changes and versions of requirements is very important Software Artifacts – Code Spread over different files, and in a directory structure Language conventions or requirements o E.g. Java has a file for each class ฀ Package hierarchy Documentation may be derived from the source code Maintainability and extensibility non-functional properties for a software o Design and architecture play important role o E.g. Model-View-Controller o Layered architecture Artifacts Items that represent work done, in ways that others can use: code, requirements specifications Artifacts go through evolution How much impact if these are lost or changes are lost or not tracked How much effort was it to create them? The artifacts have value and need to be preserved, communicated, maintained, protected from unauthorized access, etc Code Artifacts – Version Control Version control: a method for recording changes to a file or set of files over time so that you can recall specific versions later o Also called: control and source control o Create, maintain and track history of changes during the SDLC for all artifacts Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 Version Control System (VCS) Software tools to software teams to manage changes to source code over time o Keep track of every modification to code in a repository o Revert selected files back to previous state o Compare changes over time o Check who last modified sth. That might be causing a problem o Who introduced an issue and when o Compare earlier versions of the code to help fix bugs while minimizing disruption to all team members Local Version Control Programmers long ago developed local VCSs; E.g. Revision Control System (RCS) early VCS RCS works by keeping patch sets (i.e. the differences between files) Centralized Version Control (CVC) CVCSs support collaborative development A single server contains all versioned files and a number of clients check-out files from it Better than local VCS o Everyone is updated o Easier admin – fine-grained control Single point of failure o Developer’s work interrupted o Hard disk becomes corrupted, and no proper/ up-to-date backups ฀ lost entire history Distributed Version Control (DVC) Developers fully mirror the repository including the full history Several remote repositories o Developers can collaborate with different groups of people in different ways simultaneously with the same project o Can setup several types of workflows (not possible in CVC) Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 Git Fundamentals Version Control – SW Development Scenarios Multiple versions of the same software deployed in different sites and SW developers working simultaneously on updates Developers fixing some bugs/issues may introduce some others as the program develops Two versions of the software may be developed concurrently Git A version control system that helps development teams to manage changes to source code overtime Web-based (online) central repository of code and track of changes o Tracing history of changes, commits, branches, merges, conflict resolution o Collaborate and update repository through command-line and GUI Public and private repositories Git thinks about its data as a stream of snapshots of a small file system o Git doesn’t store unchanged files, it just link to previous identical file already stored Delta-based VCSs (Differences) VCSs that store as a set of files and the changes made to each file over time o Example: CVS and subversion Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 Git – Basics Nearly every operation is local o e.g. to browse the project history, Git reads it directly from your local database o work and commit changes to local copies offline Git has built-in Integrity o Using check-sum (SHA-1 hash) before it is stored and is reference it o Git stores everything in its database by the hash value of its contents ⇒ E.g., 77a8da644e2252987aa493b52f8696cd6d3f328765 Git generally only adds data o After committing a snapshot, it is very difficult to lose (you can undo things) Git has three states o Committed: file is safely stored in your local database o Modified: file has been changed but not committed it to the local database o Stages: a modified file has been marked in its current version to go into next commit snapshot Git – Structure Git directory (repository) o Metadata and object database o What is copied when you clone a repository from another computer Working directory (tree) o A single checkout of one version of the project o These files are pulled out of the compressed database and placed on disk for you to use or modify Staging area (index) o A file stores information about what will go into next commit Git – Basic Workflow Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 3 Tools and Technologies for Controlling Artifacts (2) – Advanced Collaborative Development Distributed Git – Remote Branches Remote (Hosted) Repository A remote repository is generally a simple repository – the contents of your project’s.git directory and nothing else One-person project o Local repository should suffice – includes working directory o Track changes and history of development as individual Team-based (collaboration) projects o Remote repo team members (collaborators) can access anytime o More reliable common repo (rather own local repo) o All team members can push and pull o Need to have some coordination and permission control Remote Branches Remote references: reference (pointers) in your remote repos Remote-tracking branches: references to the state of remote branches o Local references you cannot move; git moves them for you to make sure they accurately represent the state of the remote repo Remote references o git ls-remote [remote]: get full list of remote references o git remote show [remote]: get list of remote branches Remote-tracking branches o Form: / o E.g. check the origin/ master branch to see the master branch on your origin remote look like o Example: you have a git server on your network (git.ourcompany.com) Note: origin is the default name for a remote when you run git clone ⇒ git clone git.ourcompany.com will ✓ names it origin ✓ pulls down all its data ✓ creates a pointer to where its master branch is and call it origin/mater locally ✓ Set your own local master branch starting at the same place as origin’s master branch o git clone -o MyBranch to name your default remote branch MyBranch/ master Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 Local and Remote Branches sync work: git fetch origin o Fetches changes you do not have from the remote and update your local repo – move origin/ master pointer Pushing: to share local branch, explicitly push it to a remote you have write access to o git push origin servfix ฀ “take my serverfix local branch and push it to update the remote’s serverfix branch o git push origin serverfix:serverfix ฀ “take my serverfix and make it the remote’s serverfix o A collaborator wants to fetch serverfix from the remote: git fetch origin o They get a reference to where the server’s version of serverfix is under the remote branch origin/ serverfix ⇒ They only have an origin/serverfix pointer that they can’t modify Merge/Base: to merge this work into your working branch: This gives you a local branch that you can work on that starts where origin/ serverfix is Distributed Git – Distributed Workflows Centralized VCSs Single collaboration model (centralized workflow) o Every developer is a node working on a central shared repo. and sync. to it git branching: hundreds of developers work on a single repo. via many branches simultaneously Create a repo. and give every developer push access (git will manage versioning) Distributed VCS Every developer can be o Node: contribute code to other repos o Shared repo.: maintain a public repo. on which others can base their work and which they can contribute to Wide range of workflow possibilities for projects/teams Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 Distributed VCS – Integration – Manager Model Often includes a canonical repo. that represents the “official Project o Each developer has written – access to their own public repo. and read-access to everyone else’s o Developers make their own public clone of the project and push their changes to it o Then they inform the maintainer of the main project pull their changes o The maintainer add developer’s repo as a remote, test changes locally merge them into the branch and push back to their repo Workflow: 1. The project maintainer pushes to their public repository 2. A contributor clones that repository and makes changes 3. The contributor pushes to their own public copy 4. The contributor sends the maintainer an email asking them to pull changes 5. The maintainer adds the contributor’s repository as a remote and merges locally 6. The maintainer pushes merged changes to the main (blessed) repository Use: o Very common workflow in hosted servers such as GitHub and GitLab o Easy to fork a project and push your changes into your fork for everyone to see o Developers can continue to work on their repos. while the maintainer of the main repo. can pull their changes at anytime o Contributors do not have a wait for the project to incorporate their changes – each can work on their pace Distributed VCS – Dictator and Lieutenants Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 Dictator and Lieutenants Model Variation of multiple-repository workflow Lieutenants: various integration managers oversee certain parts of the repo Benevolent dictator: all Lieutenants have one integration manager The benevolent dictator pushes from their directory to a reference repo. from which all the collaborators need to pull Workflow: 1. Regular developers work on their topic branch and rebase their work on top of master. The master branch is that of the reference repository to which the dictator pushes 2. Lieutenants merge the developers’ topic branches into their master branch 3. The dictator merges the lieutenants’ master branches into the dictator’s master branch 4. Finally, the dictator pushes that master branch to the reference repo. so that the other developers can rebase on it Use: o Useful for very big projects or highly hierarchical environments o The dictator can delegate much of the work and collect large subsets of the code at multiple points before integrating them Remote Repository Remote Repo. – Running Own Server Hosting our code/ projects on your own server o Configure which protocols your server to communicate with o Typical server set-ups using the configured protocols Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 Remote Repo. – Running Hosted Server Set-up your code repo. on a hosted server (Git server) o No major concerns about security or privacy o Avoid the hassle of setting and maintaining your own server Many hosting services including GitHub, GitLab, BitBucket, Mercurial o Not Git itself but a hosting service for Git repos o Host your own projects and open it up to collaboration ⇒ Create organization, teams and repos ⇒ Web-based and desktop/ command-line interactions ⇒ Public Repos.: all GitHub functionality with free accounts but all projects are public ⇒ Private Repos: protected access and full control but it might not be free with some hosting services Hosted Servers - GitHub There are large number of Git hosting options Create one-user (personal) account Public and private repos. GitHub – Organizations Groups of people to collaborate across many projects at the same time in organizations account via organization account Organization’s member can have: o Owner: complete administrative access to the organization o Member: default role for everyone else Owners can manage members’ access to the organization’s repos. And projects with fine-grained permission controls Can add collaborators from outside of the organization (consultant) to have access to one or more organization repos. Without being a member of the organization GitHub – Organization Access Control Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 4 System Build Automation Software Configuration Management Configuration Management (CM) Configuration Management (CM) is concerned with the policies, processes and tools for managing changing software systems Track of what changes and component versions incorporated into each system version Essential for team projects to control changes made by different developers Configuration Management Activities System building: assembling program components, data and libraries, then compiling these to create an executable system Version management: keeping track of the multiple versions of system components and ensuring that changes made to components by different developers do not interfere with each other Change management: keeping track of requests for changes to the software from customers and developers, working out the costs and impact of changes, and deciding the changes should be implemented Release management: preparing software for external release and keep tracking of the system versions that have been released for customers Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 Multi-version System Development Version Management (VM) Keep track of different versions of software components or configuration items and the systems in which these components are used Ensuring changes made by different developers to these versions do not interfere with each other The process of managing code-lines and baselines ○ Baselines: Version Management can be thought of as the process of managing codelines and baselines Codeline: a sequence of versions of source code with later versions in the sequence derived from earlier versions ○ system’s components often have different versions Baseline: a definition of a specific system ○ specifies the component versions that are included in the system + a specification of the libraries used, configuration files, etc. ○ Baselines may be specified using a configuration language, to define what components are included in a version of a particular system ○ Useful for recreating a specific version of a complete system e.g. individual system versions for different customers. if a customer reports bugs in their system one can recreate the version delivered to a specific customer Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 Semantic Versioning (SemVer) set of rules and requirements that determine how version numbers should be assigned and incremented for software being developed ○ semantic numbers; numbers with meaning in relation to a certain version Why? ○ managing versioning numbers in a meaningful and standard way ○ managing dependencies: the bigger your system grows, the more packages/ libraries/ plugins you integrate into your software Given a version number MAJOR.MINOR.PATCH, increment the: 1. MAJOR version when you make incompatible API changes 2. MINOR version when you add functionality in a backwards-compatible manner 3. PATCH version when you make backwards-compatible bug fixes Example: Agile Development in CM Agile development, where components and systems are changed several times per day, is impossible without using CM tools The definitive versions of components are held in a shared project repository and developers copy these into their own workspace They make changes to the code then use system building tools to create a new system on their own computer for testing. Once they are happy with the changes made, they return the modified components to the project repository System Building Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 System building is the process of creating a complete, executable system by compiling and linking the system components, external libraries, configuration file, etc System building tools and version management tools must communicate as the build process involves checking out component versions from the repo managed by the version management system The configuration description used to identify a baseline is also used by the system building tool Software Build Automation Tools Tools for Agile Development Build Tools - Apache Ant Java-based software build tool for automating build processes ○ requires Java platform and best suited for building Java projects Does not impose coding conventions Does not impose any heavyweight dependency management framework XML to describe the code build process and its dependencies ○ Default build.xml Example: limitations: ○ too flexible ○ complexity (XML-based build files): need to specify a lot of things to make simple builds ○ no standard structure/ layout: developers can create their own structure/layout of the project Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 Apache Maven A build automation tool primarily for java projects XML-based description of the software being built ○ dependencies on other external modules and components, the build order, directories, and required plug-ins Central repository (e.g., Maven 2) Coding by convention: it uses conventions over configuration for the build procedure Supported by Eclipse, IntelliJ, JBuilder, NetBeans plugin-based architecture ○ Plugin for the.NET framework and native plugins for C/C++ are maintained Maven projects are configured using Project Object Model (POM) stored in a pom.xml file Project Structure: the common mvn package will ○ compile all the files ○ run any tests ○ package the deliverable code and resources into target (e.g. target/my-app-1.0.jar) Central Repository: ○ Maven uses default Central Repository that maintains required software artifacts (libraries, plug-ins) to manage dependencies ○ E.g. project that is dependent on the Hibernate library need to specify that in the pom.xml project file maven checks if the referenced dependency is already in the user’s local repository it references the dependency from the local repository or Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 dynamically download the dependency and the dependencies that Hibernate itself needs (transitive dependency) and store them in the user’s local repository ○ You can configure repositories other than the default (e.g. company-private repository) Disadvantages: ○ XML-based file increase complexity ○ Rigid; developers are required to understand follow the conventions Gradle Build automation tool that builds upon the concepts of Ant and Maven ○ build conventions, and redefine conventions ○ Project described using Groovy-based Domain Specific Language (DSL) ○ Tasks orders determined using a directed acyclic graph (DAC) ○ Multi-project builds ○ Incremental builds; up to date parts of the build tree do not need to be executed ○ Dependency handling 9 transitive dependency management) Groovy ○ Gradle build field are Groovy scripts ○ Groovy is a dynamic language of the JVM can be added as a plug-in allows developers to write general programming tasks in the build file relief developers from the lacking control flow in Ant or being forced plug-in development in Maven to declare nonstandard tasks DSL ○ Gradle also presents a DSL tailored to the task of building code not general-purpose or programming languages gradle DSL contains the language needed to describe how to build Java code and create a WAR file from the output ○ Gradle DSL is extensible through plug-ins Extensible DSL ○ Extensibility using plug-ins (if it doesn’t have the language to describe what you want your build to do) e.g. describe how to run database migration scripts or deploy code to a set of cloud-based QA servers ○ Gradle plug-ins allow: adding a new task definitions change the behavior of existing tasks add new objects create keywords to describe tasks that depart from the standard Gradle categories Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 Gradle Basics Gradle - Tasks Task: a single atomic piece of work for a build ○ e.g. compiling classes Project: a composition of several tasks ○ e.g. Creation of a jar file Each tasks has a name, which can be used to refer to the task within its owning project, and a fully qualified path, which is unique across all tasks in all projects Gradle - Task Actions A task is made up of sequence of Action Objects ○ Action.execute(T) to execute a task Add actions to a task ○ Task.doFirst() or Task.doLast() Task action exceptions ○ StopActionException to abort execution of the action ○ StopExecutionException to abort execution of the task and continue to the next task Gradle - Simplest Build File Example Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 Gradle - Build Lifecycle Phases of executing a build file in Gradle: Initialization: projects are to participate in the build Configuration: task objects are assembled into an internal object model called Directed Acyclic Graph (DAG) Execution: build tasks are executed in the order required by their dependency relationship Gradle - Task Configuration Configuration block: to setup variables are data structures needed by the task action when it runs in the build ○ make tasks rich object model populated with information about the build ○ runs during gradle’s configuration lifecycle when task actions executed Closure: a block of code specified by curly braces ○ holding blocks of configuration and build actions Example: Gradle - Tasks are Objects Every task is represented internally as an object ○ Task’s methods and properties ○ Gradle creates an internal object model of the build before executing it ○ Each new task is a DefaultTask type - task type can be changed ○ DefaultTask contains functionality required for them to interface with Gradle project model Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 Methods of Default Task dependsOn() Example: doFirst() Example: onlyIf() Example Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 Gradle - Default Task’s Properties Gradle - Dynamic Properties Properties (other than built-in ones) can be assigned to a task A task object functions can contain other arbitrary property names and values we want to assign to it (do not use built-in property names) Gradle Task Types Copy ○ A copy task copies file from one place into another Jar ○ A hard task creates a jar file from source files ○ The Java plug-in’s jar creates a task of this type ○ It packages the main source set and resources together with a trivial manifest into a jar bearing the project’s name in the build/libs directory ○ Highly customizable Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 JavaExec ○ A JavaExec task runs a Java class with a main() method ○ Tries to take the hassle away and integrate command-line Java innovations into your build Gradle Custom Task Types Gradle’s built-in tasks might not be sufficient for all scenarios Gradle allows defining custom task types in: ○ The Build File and must extend the DefaultTask class or one of its descendants Example: suppose your build file need to issue arbitrary queries against a MySQL database ○ The Source Tree: when the task’s logic is significant has its own class hierarchy and might rely on external interface When the custom task logic outgrows the build file, it can be migrated to the buildSrc directory at the project root This directory is automatically compiled and added to the build classpath Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 Gradle - Plug-ins Gradle - Java Plug-in A plug-in is an extension to Gradle which configures projects Java Plug-in adds some tasks to your project which will compile and unit test your Java source code, and bundle into a JAR ○ Convention-based; default values for many aspects of the project are pre-defined In your build.gradle: apply plugin: ‘java’ ○ Can customize projects if you do not follow the convention Project Structure: ○ Gradle expects to find production source code under src/main/java and test source code under src/test/java ○ Files under src/main/resources will be included in the JAR as resources ○ Files under src/test/resources will be included in the classpath used to run tests ○ All output files are created under the build directory, with the JAR file will end up in the build/libs directory Project Build: ○ Java plug-in will add a few tasks ○ Run gradle tasks to list the tasks of a project ○ Gradle will compile and create a JAR file containing main classes and resources - run gradle build ○ clean: deletes the build directory, removing all built files ○ assemble Compiles and jars your code, but does not run the unit tests Other plugins add more artifacts to this task ○ check Compiles and test your code Other plugins add more checks to this task; e.g. checkstyle plugin to run checkstyle against your source code Dependencies ○ Reference external JAR files that the project is dependent on: JAR files in a repository (artifacts/ dependencies needed for a project) Different repo. types are supported in Gradle Example (using Central Maven Repo.) Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 Project Customization ○ The Java plug-in adds many properties with default values to a project ○ Customize default values to suit project needs ○ Use Gradle properties to list properties of a project Publish JAR file ○ Artefacts such as JAR files can be published to repo. ○ To publish a JAR file: gradle uploadArchives Gradle - Complete Build File for Java Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 5 Software Quality Assurance: Software Testing Software Quality Assurance Software quality ○ Satisfying end user's needs; correct behaviour, easy to use, does not crash, etc ○ Easy to the developers to debug and enhance Software Quality Assurance ○ Ensuring software under development have high quality and creating processes and standards in organization that lead to high quality software ○ Software quality is often determined through Testing Software Testing - Costs Software development and maintenance costs Total costs of inadequate software testing on the US economy is $59.5bn Need to develop functional, robust and reliable software systems ○ Human/ social factor - society dependency on software in every aspect of their lives Critical software systems - medical devices, flight control, traffic control ○ Meet user needs and solve their problems ○ Small software errors could lead to disasters Software Testing Software process to ○ Demonstrate that software meets its requirements ○ Find incorrect or undesired behaviour caused by defects/ bugs e.g. System crashes, incorrect computations, unnecessary interactions and data corruptions Different system properties ○ Functional: performs all expected functions properly ○ Non-functional: secure, performance, usability Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 Testing Objectives “Program testing can be used to show the presence of bugs, but never to show their absence” Objectives should be stated precisely and quantitatively to measure and control the test process Testing completeness is never been feasible ○ So many test cases possible - exhaustive testing is so expensive! ○ Risk-driven or risk management strategy to increase our confidence How much testing is enough? ○ Select test cases sufficient for a specific purpose (test adequacy criteria) ○ Coverage criteria and graph theories used to analyse test effectiveness Tests Modelling Testing modelled as input test data and output test results Tests that cause defects/ problem (defective testing) Tests that lead to expected correct behaviour (validation testing) Who does Testing? Developers test their own code Developers in a team test one another’s code Many methodologies also have specialist role of tester ○ Can help by reducing ego ○ Testers often have different personality type from coders Real users, doing real work Testing takes creativity To develop an effective test, one must have: ○ Detailed understanding of the system ○ Application and solution domain knowledge ○ Knowledge of the testing techniques Testing is done best by independent testers ○ We often develop a certain mental attitude that the program should be in a certain way when in fact it does not ○ Programmers often stick to the data set that makes the program work ○ A program often does not work when tried by somebody else Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 When is Testing Happening? Waterfall Software Development ○ Test whether system works according to requirements Agile Software Development ○ Testing is at the heart of agile practices ○ Continuous integration ○ Daily unit testing Software Testing Process Design, execute and manage test plans and activities ○ Select and prepare suitable test cases (selection criteria) ○ Selection of suitable test techniques ○ Test plans execution and analysis (study and observe test output) ○ Root cause analysis and problem-solving ○ Trade-off analysis (schedule, resources, test coverage or adequacy) Test effectiveness and efficiency ○ Available resources, schedule, knowledge and skills of involved people ○ Software design and development practices (“Software testability”) Defensive programming: writing programs in such a way it facilitates validation and debugging using assertions Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 Types of Defects in Software Syntax error ○ Picked up by IDE or at least in build process ○ Not by testing Runtime error ○ Crash during execution Logic error ○ Does not crash, but output is not what the spec asks it to be Timing error ○ Does not deliver computational result on time Software Testing Levels Testing Levels Integration Testing The process of verifying interactions/ communications among software components behave according to its specifications Incremental integration testing vs. “Big Bang” testing Independently developed (and tested) units may not behave correctly when they interact with each other Activate corresponding components and run high-level tests Acceptance Testing Process Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 Regression Testing Verifies that a software behaviour has not changed by incremental changes to the software Modern software development processes are iterative/ incremental Changes may be introduced which may affect the validity of previous tests Regression testing is to verify ○ Pre-tested functionality still working as expected ○ No new bugs are introduced Software Testing Techniques Principle Testing Techniques Black-box Testing ○ No programming and software knowledge ○ Carried by software testers ○ Acceptance and system testing (higher levels) White-box Testing ○ Software code understanding ○ Carried by software developers ○ Unit and integration testing (lower level) Black Box Testing - Example Test planned without knowledge of the code Based only on specification or design E.g. given a function that computes sign(x+y) Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 Test-Driven Development (TDD) A particular aspect of many (not all) agile methodologies Write tests before writing code And indeed, only write code when needed in order to pass tests! Test Cases Design Choosing Test Cases - Techniques Partition Testing ( partitioning) ○ Identify groups of inputs with common characteristics ○ For each partition, choose tests on the boundaries and close to the midpoint Guideline-based Testing ○ Use testing guidelines based on previous experience of the kinds of error often made ○ Understanding developers thinking Equivalence Partitioning Different groups with common characteristics ○ e.g. +ve no., -ve no. Program behave in a comparable way for all members of a group Choose test cases from each of the partitions Boundary cases ○ Select elements from the edges of the equivalence class Code (Test) Coverage The extend to which a source code has been executed by a set of tests Usually measured as percentage e.g. 70% coverage Different criteria to measure coverage ○ e.g. method, statement, loop Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 Coverage Criteria Coverage Target What coverage should one aim for? Software criticality determine coverage level Extremely high coverage for safety-critical (dependable) software ○ Government/ standardization organizations E.g. European cooperation for space standardization 100% statement and division coverage fo 2 out of 4 criticality levels Tools for Agile Development Unit Testing Terminology Unit Test ○ Code written by a developer that executes a specific functionality in the code under test and asserts a certain behaviour/ state ○ E.g. method or class ○ External dependencies are removed (mocks can be used Test Fixture: the context for testing ○ Usually shared set of testing data ○ Methods for setup these data Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 Test Frameworks Software that allows test cases to be described in standard form and run automatically Tests are managed and run automatically, and frequently Easy to understand reports ○ Big Green or Red signal For Java: ○ Junit ○ TestNG ○ Jtest (commercial) Unit Testing Frameworks - Junit An open source framework for writing and running tests for Java Uses annotations to identify methods that specify a test Can be integrated with Eclipse, and build automation tools (e.g. Ant, Maven, Gradle) JUnit - Constructs JUnit test (Test class) ○ A method contained in a class which is only used for testing (called test class) Test suite ○ Contains several test classes which will be executed all in the specified order Test Annotations ○ To define/ denote test methods (e.g. @Test, @Before) ○ Such methods execute the code under test Assertion methods (assert) ○ To check an expected result vs. actual result ○ Variety of methods ○ Provide meaningful messages in assert statements JUnit - Annotations Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 Example: JUnit - Assertions Assert class provides static methods to test for certain conditions Assertion method compares the actual value returned by a test to the expected value ○ Allows you to specify the expected and actual results and the error message ○ Throws an AssertionException if the comparison fails JUnit - Static Import Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 JUnit - Executing Tests From the command line ○ runClass(): org.junit.runner.JUnitCore class allows to run one or several test classes org.junit.runner.Result object maintain test results Test automation ○ Build tools (e.g. Maven. Gradle) along with Continuous Integration Server (e.g. Jenkins) can be configured to automate test execution ○ Essential for regular daily tests (agile development) Example: JUnit Test Suites Junit - Test Execution Order Junit assumes that all test methods can be executed in an arbitrary order Good test code should not depend on other tests ad should be well defined You can control it but it will lead into problems (poor test practices) By default, Junit 4.11 uses a deterministic order (MethodSorters.DEFAULT) @FixMethodOrder to change test execution order (mot recommended practice) ○ @FixMethod Order(MethodSorters.JVM) ○ @FixMethod Order (MethodSorters.NAME ASCENDING) Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 JUnit - Parameterized Test A class contains a test method and that test method is executed with different parameters provided Marked with @RunWith(parameterized.class) annotation The test class must contain a static method annotated with @Parameters ○ This method generates and returns a collection of arrays. Each item in this collection is used as a parameter for the test method Example: JUnit - Verifying Exceptions Verifying that code behaves as expected in exceptional situations (exceptions) is important The @Test annotation has an optional parameter “expected” that takes as value subclasses of Throwable Junit - Verify Tests Timeout Behaviour To automatically fail tests that ‘runaway’ or take too long: Timeout parameter on @Test ○ Cause test method to fail if the test runs longer than the specified timeout ○ timeout in milliseconds in @Test Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 Junit-Rules A way to add or redefine the behaviour of each test method in a test class ○ e.g. specify the exception message you expect during the execution of test code Annotate fields with the @Rule Junit- ErrorCollector Rule Example Junit- Eclipse Support Create Junit tests via wizards or write them manually Eclipse IDE also supports executing tests interactively ○ Run-as Junit Test will starts JUnit and execute all test methods in the selected class Extracting the failed tests and stack traces Create test suites Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 Tests Automation - Junit with Gradle To use Junit in you Gradle build, add a testCompile dependency to your build file Gradle adds the test task to the build and needs only appropriate Junit JAR to be added to the classpath to fully activate the test execution Code Coverage Tools Tools for Code Coverage in Java There are many tools/ plug-ins for code coverage in Java Example: EclEmma* EclEmma is a code coverage plug-in for Eclipse ○ It provides rich features for code coverage analysis in Eclipse IDE ○ EclEmma is based on the JaCoCo code coverage library JaCoCo is a free code coverage library for Java which has been created by the EclEmma team Source Code Annotations Source lines color code: ○ Green for fully covered lines ○ Yellow for partly covered lines (some instructions or branches missed) ○ Red for lines that have not been executed at all Diamonds color code: ○ Green for fully covered lines ○ Yellow for partly covered lines ○ Red when no branches in the particular line have been executed Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 6 Continuous Integration, Continuous Delivery and Development Agile Development Agile Principles The highest priority is to satisfy the customer through early and continuous delivery of valuable software Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale Working software is the primary measure of progress Agile Development - Integration Integration is a regular activity in a agile development Continuous Integration (CI) “A software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible” – Martin Fowler, 2006 Suppose that two developers are working on two separate components; A and B. Each thinks they complete their work, code of both components need to be integrated and verified to deliver consistent & expected behaviour of the system Individual developers may work on components integrated into subsystems Sub-systems may be integrated with other team’s subsystems for a large system The goal is to ensure that the software is always in a working state ○ Every time somebody commits any change, the entire application is built and a comprehensive set of automated tests is run against it ○ If the build or test process fails, the development team stops whatever they are doing and fixes the problem immediately Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 Continuous Objective Minimise the duration and effort required by each integration Be able to deliver product version suitable for release at any moment To achieve these objectives: ○ Integration procedure which is reproducible ○ Largely automated integration Continuous Integration - Costs Bugs are caught much earlier in the delivery process when they are cheaper to fix, providing significant cost and time savings Continuous Integration and Tooling CI should not be confused with the tools that assist it ○ CI is a development practice not tools ○ Different automation tools can be used including version control, system build and testing CI should lessen the pain of integration by increasing its frequency CI - Implementation Use of a version control tool (e.g. CVS, SVN, Git) Use of automated build process Commitment and discipline from development teams (practice) Configuration of the system build and testing processes Use of CI server to automate the process of integration, testing and reporting of test results (optional) Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 Continuous Integration Workflow Workflow (1) 1. A developer check-out the system mainline from the VC system 2. Build the system and run automated tests to ensure the build system passes a. Tests not passed, notify the developer who check-in the last baseline of the system 3. They make the changes to the system components (e.g. add new feature) 4. They build the system in a private workspace and return system tests a. if the tests fail, they continue editing Workflow (2) 5. System passed tests, they check it into the build system server 6. Build the system on the build server and run the tests a. Changes committed by other developers since last check-out, these need to be checked out and tests should pass on the developer’s private space 7. Commit the changes they have made in the system mainline Effective CI - Automation Practices Automation Practices (1): Regular Check-in Developers to check in their code into the mainline regularly (at least couple of times a day) ○ Small changes less likely to break the build ○ Easier to revert back to last committed version Check-in vs branching ○ Working on branch means your code is not being integrated with other developer’s code, especially long-lived branches Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 Automation Practices (2): Create a comprehensive automated test suite Three types of automated tests should considered in CI build: ○ Unit Testing: test the behavior of small pieces in isolation ○ Component Testing: test the behaviour of several components ○ Acceptance Testing: test if the application meets the acceptance criteria set by end users (functional and non-functional) These sets of tests should provide high level of confidence that any introduced change has not broken existing functionality Automation Practices (3): Keep the build and test process short Developers may stop doing ufll build and running the test before they check-in CI will likely miss multiple commits if it takes too long Lead to less check-ins as developers wait for the software to build and tests to run Should aim for 1.5 to 10mins (depending on the application size) Optimize your tests to achieve same coverage Split testing into two stages: ○ Compile software and run suite of unit tests and create deployable binary ○ Use binary to run acceptance, integration and performance tests Automation Practices (4): Developer’s to manage their development workspace They should be to build, run automated tests and deploy on their local machines using the same processes used in the CI Automation Practices (5): Use CI Software CI activities often has 2 components ○ CI workflow execution It polls VCS, check out a copy of the project to a directory on the server if it detects changes It execute commands to build the application and run automated tests ○ CI results visualization and reporting Results of the processes that have been run, notifies you of the success or failure of the build and automated tests and provide access to test reports Effective CI: Essential Practices - Development Teams Team Practices (1): Don’t check in on a broken build If the build fails, responsible developers will need to find the cause of breakage and fix it quickly CI process will always identify such breakage and will likely lead to interrupting other developers in the team Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 Team Practices (2): Always run all commit test locally, or get your CI server to do it for you Other check ins before your last update from the VCS Check-in indicates that either a developer forgot to add some new artefacts to the repository, or someone checked-in in the meantime Modern CI servers offer pretested commit, personal build ○ The CI server will take your local changes and run a build with team on the CI environment Either check-in you changes or notifies you of build failure Team Practices (3): Wait for commit tests to pass before moving on CI is shared among all developers Keep the system in consistent and stable state Fix failure without interrupting the workflow Team Practices (4): Never go home on a broken build No broken build Check-in regularly and early enough to give yourself time to deal with problems If fails, revert your change from source control and leave it in your local working copy Team Practices (5): Always be prepared to revert to the previous revision Fix it quickly or revert and fix it locally On of the VCS benefits Mindset - be prepared Team Practices (6): Time-box fixing before reverting Set a team rule; fixed it within X-minute or revert Think of other team members Team Practices (7): Do not comment out failing tests Often a result of the time-box fixing It takes time to find the root cause of tests failing ○ Are test cases no longer valid given many changes made to the application? ○ you may need to talk to other developers Team Practices (8): Take responsibility for all breakages that result from your changes It is your responsibility, because you made the change, to fix all tests that are not passing as a result of your changes To fix breakages, developers should have access to any code that they can break through their changes Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 Continuous Delivery (CD) “Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time.” – Martin Fowler, 2013 Release new changes to customers quickly and in reproducible way Automate the release process so you can deploy your application at any time ○ packaging artefacts (using automated building tools) to be delivered to end users Reason of Using CD “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” - Agile Manifesto Cycle time in hours not months Quality should be built-in to the process Late feedback is expensive! CD - Deployment Pipeline An automated implementation of the application’s build, deploy, test and release process Has its foundations in the process of CI Example of deployment pipeline Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 Case Study - Yahoo and Flickr CD - Industry Examples Amazon (2011): 11.6s between deployment Facebook (2013): 2 deployments a day HubSpot (2013): 300 deployments per day! Atlassian (2016): 65% of customers practice con Automated continuous delivery Continuous Deployment “The practice of releasing every good build to users - a more accurate name might have been ‘continuous release’” - Jez Humble, 2010 Difference between Continuous Delivery and Continuous Deployment Deployment Automation Deployments should tend towards being fully automated ○ Pick version & environment ○ Press “deploy” button Automated deployment scripts should be up-to-date Don’t depend on the deployment expert Automated deployment process: ○ Cheap and easy to test ○ Fully auditable ○ Should be the only way in which the software is ever deployed Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 CI/ Delivery tools - Jenkins Jenkins Jenkins is an automation server to automate tasks related to building, testing, and delivering or deploying software Jenkins pipeline supports implementing and integrating CD pipelines into Jenkins ○ CD pipeline is an automated expression of your delivery process ○ Written in Jenkinsfile Jenkins - Running Multiple Steps Building, testing and deploying activities are defined as stages and steps Jenkins allow composing different steps (commands) to model simple and complex automation processes Special steps: ○ Retry: retying steps a number of times (e.g., retry(4)) ○ Timeout: exiting if a step takes long time (timeout (time: 3, unit: MINUTES)) ○ Clean-up: to run clean-up steps or perform post actions based on the outcome of the pipeline when it finishes executing Jenkins - Execution Environment The agent directive specifies how to execute pipeline ○ All steps contained within the block are queued for execution ○ A workspace is allocated which will contain files checked out from source control and any additional files for the pipeline Pipeline is designed to use Docker images and containers to run inside ○ No need to configure various tools and dependencies on agents manually Jenkins - Recording Tests and Artifacts Junit already bundles with Jenkins Jenkins can record and aggregate all test results and artefacts ○ Reported through using the post section ○ A pipeline that has failing tests will be marked as UNSTABLE Jenkins stores files generated during the execution of the pipeline (artifacts) ○ Useful for analyzing and investigation in case of test failures Jenkins - Cleaning and Notifications Post section can be used to specify clean up tasks, finalization or notifications ○ Post section will run at the end of the pipeline execution ○ e.g., lean up our workspace, delete unneeded directories Notifications can be set-up to ○ Send emails ○ Post on Slack or other Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 7 Team Dynamics; Tools and Technologies for Teamwork Teams in Software Development Models Waterfall Model - Teams Teams under Different SDLC models In a traditional structure how do teams work? ○ As work is planned and allocated, it can be divided into pieces that should be more-or-less independent Specialist teams Project management and resource reallocation Clear authority lines, so disagreements can be resolved ○ Problems: Single points of failure Inflexibility Lack of feedback Teams in Agile Development Agile Manifesto Individuals and interactions over processes and tools ○ Reason: People tend to follow processes bindly, and make mistakes “A great tool can sometimes help people to do the wrong thing faster” Tools or best practices are not enough - people who need to use it should buy into it to realize its benefits People needs to see the value of following certain practices ○ It is important to recognise that you are working with a group of people who have different motivations, ideas and preferences Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 Agile Principles 1 - People Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done The most efficient and effective method of conveying information to and within a development team is face-to-face conversation At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly Group Discussion: ○ Briefly discuss how the following agile principles perceive teams and teamwork in agile development? Agile Principles 2 - People Business people and developers must work together daily throughout the project The best architectures, requirements, and designs emerge from self-organizing teams Our highest priority is to satisfy the customer through early and continuous delivery of valuable software Teams - Individuals and Collaborations Common problem experienced in software development teams “throw it over the wall” ○ Team members are busy thinking about their own project work and problems Different views/ perspectives ○ Teams are divided, and collaboration is killed Agile Practices - The Agile Elephant The agile elephant is made up of many practices Agile Teams - Individual Practices When adopting agile practices, team members may adopt practices individually: ○ Each person uses only the practices that impact their work; developers focus on automated tests and build, team leads on task boards, project velocity and burn-down charts, business users on user stories ○ Adopting practices individually will improve things, but this may lead to a self-contradictory effect Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 Teams - Individual Practices When adopting agile practices, team members may follow the same thinking: ○ Each person uses only the practices that impact their work; developers focus on automated tests and build, team leads on task boards, project velocity and burn-down charts, business users on user stories ○ Adopting practices individually will improve things, but this may lead to a self-contradictory effect Each person sees the part of agile that affects their specific work (attitudes: “see! I was right all along”) Agile is made up of day-to-day practices, but it’s much bigger than those practices Team Dynamics “Team dynamics are the unconscious, psychological forces that influence the direction of a team’s behaviour and performance” Factors that lead to team dynamics: ○ Personalities and work styles ○ Knowledge and skills ○ Organization culture and structure ○ Cultural differences, background Pros ○ E.g. improve overall team performance (productive conflict, different perspectives) Cons: ○ Can lead to unproductive conflict can demotivate and prevent team from achieving its goals Tuckman Team Development Model Identifications and Resolution ○ Result from the interaction of many factors E.g., Personalities, work style, roles, culture, organizational structure ○ Investigate the root causes of conflict or poor team performance Structured interviews or informal chats in a private and confidential ○ Identify potential improvements E.g., change in office layout, team development workshops (practices, personality dynamics, cultural change programs) Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 Agile Teams - Skills It’s claimed that agile teams work with the best developers. However, this is not necessary the case ○ Every project needs at least one experienced and competent lead person (Critical Success Factor) ○ Each experienced and competent person on the team permits the presence of 4-5 “coverage” or learning people ○ With that skill mix, agile techniques have been shown to work many times Effective Teamwork Teamwork comprises of the right tools, the right people ad the right practices Effective teamwork is everyone’s shared responsibility Large software organizations, teams involve many roles across different departments (engineering, design, sales/ marking, legal) Use team building activities to build effective teams Team Building “Various types of activities used to enhance social relations and define roles within teams, often involving collaborative tasks” There is an evidence how team building affect positively team effectiveness Team Building Activities Goal setting: emphasizes the importance of clear objectives and individual and team goals ○ e.g. objectives and key results (Atlassian) Interpersonal relations: focus on teamwork skills such as giving an deceiving support, communication and sharing information Standup meetings Roles and responsibilities (Atlassian) ○ Define the roles and responsibilities that will make your team successful ○ Clarify expectations as a team ○ Helps to move a team from “storming” to “norming”, or help “performing” teams to get back on track ○ Method: 1. create a table of roles and responsibilities a. Responsibilities from own perspective b. Responsibilities from team member’s perspective 2. Identify roles a. E.g., team lead, developers designers b. Coarse-grained c. Add to the role’s column 3. Clarify own responsibility a. Think of top 3-5 tasks in priority order b. Write on sticky notes Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 4. Think of teammate’s responsibilities a. Write 1-2 responsibilities for each role from your perspective b. Write responsibilities you may think that don’t have a clear owner 5. Refine and consolidate (optional) a. Talk teammates with similar roles and refine responsibilities 6. Discuss all roles a. Role owner(s) describe their role and place their sticky notes in own responsibility column b. Other teammate’s role description in the other column c. Owner to accept. decline the responsibilities by other teammates (suggest role to own it). Define primary owner for overlapping roles d. Add “unassigned responsibilities” to 7. Summarize roles and responsibilities a. All to agree b. Owner to document it and how to fill skill gaps High-Performing Agile Teams Cross-functional; engineers, designers, architects, sales Mutual respect and mutual responsibility ○ Not blaming culture, and/ or “throw it over the wall” Sound engineering practices (tools and automation) Value and belief of agile practices and principles Apply agile practices effectively as individuals and as a team Receive continuous training (technical and non-technical) and team monitoring/coaching How much can you find out? Search for: ○ Team effectiveness ○ Self-managed teams ○ Group conflict ○ Team efficacy Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 Tools and Technologies for Teamwork Issue Tracking Systems A software that manages and maintains lists of issues used to create, update and resolve reported issues internally or externally Bug (defect) Tracking System: keeps track of reported software bugs in software development projects ○ Centralized overview of development requests and their states ○ May assigned a priority, status, severity and/ or complexity ○ Prioritized list of pending items (Backlog) ○ Typically integrated with other tools or software management systems Bug/ Issue Tracking Part of other Systems Part of integrated project/ software development management systems It helps integrating issue/ bug tracking with other activities Distributed bug tracking tools are designed to be used with distributed revision control software Bugzilla - Bug Tracking Tool Open-source web-based bug tracker and testing tool by Mozilla project Bug (or feature) requests can be submitted by anyone and will be assigned to a particular developer Various status updates for each bug ○ e.g. Bugzilla itself allows the public to file bugs - it assigns all bugs to a gatekeeper whose job is to assign responsibility and priority level Bug Life Cycle Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 Jenkins CI/ CD “Jenkins is a self-contained, open source automation server which can be used to automate all sorts of tasks related to building, testing, and delivering or deploying software” Jenkins pipeline is a suite of plugins which supports implementing and integrating continuous delivery pipelines into Jenkins ○ A continuous delivery pipeline is an automated expression of your process for getting software from version control right through to end users/ customers ○ Typically written in Jenkinsfile which is checked in a project’s source code repository JENKINS SETUP LOOK AT ED OR LECTURE PAGE 55 Teamwork collaboration Tools Dropbox Google docs Skype Trello Slack Basecamp Asana Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 8 Agile Method - Scrum Revision - Agile Agile Process Agile advocates believe: ○ Traditional software development processes are too heavy-weight Too many things are done that are not directly related to software product being produced ○ Traditional software development is too rigid Difficulty with incomplete or changing requirements Short development cycles (internet applications) ○ More active customer involvement needed Agile process are considered ○ Light-weight ○ People-based rather than plan-based Several agile methods ○ No single agile method ○ Extreme Programming (XP), Scrum No single definition Agile Manifesto closest to a definition ○ Set of principles ○ Developed by Agile Alliance Agile Principles 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale 4. Businesspeople and developers must work together daily throughout the project 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation 7. Working software is the primary measure of progress 8. Agile processes promote sustainable development. The sponsors, develoopers, and users should be able to maintain a constant pace indefinitely 9. Continuous attention to technical excellence and good design enhances agility 10. Simplicity - the art of maximizing the amount of work not done is essential 11. The best architectures, requirements, and designs merge from self-organizing teams 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 Agile Methods All have shared goal; delivering valuable software iteratively Might have some different practices to achieve this goal ○ How coding should be done, how work is arranged daily, team structure and communication Examples of Agile methods: ○ Scrum ○ Extreme Programming (XP) ○ Lean software development ○ Kanban (lean development) eXtreme Programming (XP) Development and delivery of very small increments of functionality Relies on constant code improvement, user involvement in the development team and pair wise programming Emphasized Test Driven Development (TDD) as part of the small development interactions Any many more XP Practices Customer team member User stories Acceptance tests Pair programming Test-driven development (TDD) Short cycles Continuous integration Simple design Refactoring Collective ownership Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 Scrum Originating in a broader “product development” lifecycle ○ A new approach to increase speed and flexibility Used for software development Extensively used in various organizations (e.g. manufacturing, product development, software, hardware) An agile method for managing software development focused on delivering products of the highest value Focus on continuous improvement of the product, the team and the working environment Scrum is lightweight, simple to understand but difficult to master Scrum Theory Based on ‘empirical process control’ theory ○ Knowledge comes from experience and making decisions based on knowns ○ Iterative, incremental approach to optimize predictability and control risks Pillars of empirical process control ○ Transparency: significant aspects of the process must be visible to those responsible for the outcome ○ Inspection: Scrum users must frequently inspect Scrum artifacts and progress toward an iteration goal to detect undesirable variances ○ Adaption: adjust the aspects of the process that lead to deviation outside the acceptable limits Scrum Values The Scrum team members should learn and explore the following values as they work with the Scrum roles, events, and artifacts: ○ Commitment: personally commit to achieving the goals of the Scrum Team ○ Courage: members can do the right thing and work on tough problem ○ Focus: everyone focuses on the work of the iteration and the team’s goals ○ Openness: the team and the stakeholders agree to be open about the work and the challenges with performing the work ○ Respect: Scrum team members respect each other to be capable, independent people Scrum Practices Teams and their roles ○ Product Owner, Scrum Master, Dev Team Events ○ Sprint, Sprint Planning, Daily Scrum, Sprint Review, and Retrospective Artifacts ○ Product Backlog, Sprint Backlog, Increment Project estimation and Sprint estimation Rules govern the relationships between roles, events and artifacts Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 The Scrum Team Scrum Team Team roles ○ Development Team ○ Product Owner (one person!) ○ Scrum Master (one person!) Scrum Team ○ Small enough to be agile ○ Cross-functional ○ Self-organizing ○ Deliver products iteratively and incrementally, maximizing opportunities for feedback The Product Owner Product Owner maximize the value of the product and the work ○ Talks to customer, understand requirements and its priorities ○ Managing the Product Backlog (only person) Can assign it to the development team, but still accountable Managing the product backlog: ○ Record product backlog items and order it ○ Optimize the value of the work the development team performs ○ Ensure transparency and clarity of the product backlog ○ Ensure the development team understands product backlog The Development Team Professionals who do the work of delivering a potentially releasable product at the end of each iteration Creates the increment (only by dev team) What’s the optimal team size? Discuss ○ Small enough and large enough! ○ Less than 3 members? ○ More than 9 members Professionals who do the work of delivering a potentially releasable product at the end of each iteration Creates the increment (only by dev team) What is the optimal team size? Discuss ○ Small enough and large enough ○ Two-Pizza Team (4-9 members) ○ Less than 3; issues with productivity and interactions ○ More than 9; issues with coordination Self-organizing: turns Product Backlog into increments of potentially releasable functionality Cross-functional: skills mix necessary to create a product No sub-teams: regardless of domains that need to be addressed Whole team is accountable and No titles for Dev team members Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 The Scrum Master Keeps the team focused on using Scrum properly (“servant-leader”) ○ Everyone understands Scrum rules and values (coaching) ○ Remove impediments ○ Helps those outside the Scrum team which of their interactions with the Scrum team are/ aren’t helpful ○ Maximize the value created by the Scrum team through changing team interactions Serves the Product Owner ○ Creating mutual understanding of goals, scope and product domain ○ Finding effective ways for managing the product backlog ○ Helping the Scrum team understands the need for clear and concise product backlog items ○ Ensuring the product owner knows how to arrange the Product Backlog to maximize value ○ Understanding and practicing agility ○ Facilitating Scrum vents as requested or needed Serves the Dev Team ○ To be self-organization and cross-functionality ○ To create high-value products ○ Removing impediments to the Dev team’s progress ○ Facilitating Scrum events as requested or needed; and ○ Coaching the Dev team (in organizational environments in which Scrum is not yet fully adopted and understood) Example: Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 The Scrum Events Used to create regularity and minimize the need for meetings All events are time-boxed (max.duration) cannot be changed once an iteration (sprint) has started Designed to enable transparency and to provide a formal opportunity to inspect and adapt work Scrum Events - The Sprint A development iteration (one cycle) ○ Useable and potentially releasable product increment is created Time-boxed (typically 2-4 weeks) ○ Too long sprints may lead to changes in the definition Sprints have consistent durations during the product development Consists of the Sprint Planning, Daily Scrum, the Development Work, the Sprint Review and the Spring Retrospective Scrum Events - Sprint Planning Identify the Sprint Goal (items from the “Product Backlog”) Identify work to be done to deliver this Two parts meeting (Scrum Master, Product Owner and Dev team) ○ Before meeting: Product Owner prepares prioritized list of most valuable items ○ Meeting part 1 (max. 4 hours): Product Owner & Dev team select items to be delivered at the end of the Sprint based on their value and on the team’s estimate of how much work needed ○ Meeting part 2 (max. 4 hours): Dev team (with the Product Owner’s help) figure out the individual taska they’ll use to implement those items Output: Sprint Backlog (the items selected by the team for development) Scrum - Team Structure Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 Scrum Iteration Process Sprint (development iteration) ○ Timeboxed (typically 2-4 weeks: no more than one month) ○ Create a “Done” usable, potentially releasable product A Sprint (Scrum iteration) contains a list of tasks and work product outputs that will be done in defined duration ○ At the beginning of the Sprint duration, each team member has a pretty good idea of what they will be working on ○ Management should not add new work product outputs to the Sprint - should be added to the Product Backlog instead Scrum Events - During Sprint Daily Scrum meeting ○ To ensure problems and obstacles are visible to the team ○ Timeboxed 15 minutes (same time and place each day) ○ All team members including Scrum Master and Product Owner must attend ○ Interested stakeholders may attend as observers ○ Each briefly answers three questions: What did I do yesterday that helped the development team meet the Sprint Goal? What I will to today to help the development team meet the Sprint Goal Do I see any obstacles that prevent me or the Dev team from meeting the Sprint Goal? ○ No problem-solving during the meeting Follow-up meetings if further discussion is required Development Work; the Dev Team ○ Builds the items in the Sprint Backlog into working software ○ Should inform the Product Owner if they are overcommitted or can add extra items if time allows ○ Must update the Sprint backlog and keep it visible to everyone Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 The Sprint Review: Informal meeting at end of the Sprint(max. 4hrs) ○ Dev team demonstrates working software to customers/ stakeholders Items actually done - completed, tested & accepted by the Product Owner Only functional working software - not architecture, database design etc ○ Stakeholders share their feedback, ideas, feelings, thoughts about the demo ○ The Product Owner explains “Done” and not “Done” items ○ Output: revised Product Backlog and probable items for next iteration Scrum Events - Retrospectives Opportunity for the Scrum team to inspect itself and create plan for improvements Purpose: ○ Inspect how the last Sprint went with regards to people, relationships, process, and tools ○ Identify and order the major items that went well and potential improvements ○ Create a plan for implementing improvements to the way the Scrum Team does its work Retrospective Meetings (max. 1-2 hrs) ○ The Scrum Master and the Dev. team (maybe product owner) ○ Each person answer two questions: What went well during the Sprint? What can be improved in the future? ○ The Scrum Master notes improvements that should be added to the Product Backlog (non-functional items) E.g., set-up a better build server, adopting design principles, changing office layout ○ Output: Identified improvements to be implemented in the next Sprint (adaptation) The Retroperspectives Prime Directive: Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 Scrum Artifacts Scrum Artifacts - Product Backlog Set of all features and sub-features (items) needed to build the product (the “plan” for multiple iterations) ○ Features, functions, requirements, enhancements and fixes identified from previous Sprints Maintained by the Product Owner in collaboration with customers and team The source of the product requirements ○ Evolves over the time and never complete (dynamic) The items ordered by priority - value to the customer ○ To deliver some value to the customer in each iteration, put the most important things early What does a Product Backlog look like? ○ Simple spreadsheet ○ Some items are “customer features” Could be a user screen, an interaction scenario or use case, a new report/ algorithm ○ Some items are internal tasks that contribute to the value of the product Can a design document be an item? Can an early GUI prototype be an item? Effort estimates - assigned to each item by the Dev Team ○ Should managers do the estimation of Product Backlog Items? Scrum Artifacts - Sprint Backlog Set of Product Backlog items selected for the Sprint, and a plan for delivering the product increment and realize the Sprint Goal The Dev. team to forecasts next items to be implemented Includes at least one high-priority improvement identified from previous Sprint The Dev. team adds new work to the Sprint Backlog The estimated remaining work is updated once an item is completed Visible to anyone and to be modified by the Dev. team Example: ○ Typically divided into 3 sections; ToDo, In Progress, Done ○ Tools to support Sprint planning and monitoring; e.g., Trello Downloaded by Eddie Wang ([email protected])  lOMoARcPSD|22962037 Scrum Artifacts - The Increment Collection of the Product Backlog items that meet definition of “Done” by the end of the Sprint Definition of “Done” ○ Team’s shared agreement on the criteria that a Product Backlog item (user story) must meet before it is considered done ○ Work will not be counted toward the end of the Sprint if it does not meet the criteria Scrum Estimation Scrum - Progress Monitoring Total work remaining to reach the goal: the product owner tracks this at least every Sprint Review ○ Compare with previous Sprints to assess progress toward projected work (transparent to all stakeholders) ○ Forecasting progress thr