1 CS189A - Capstone Christopher Kruegel Department of Computer Science
2 How Should We Build Software? Let s look at an example Assume we asked our IT folks if they can do the following: Every year all the PhD students in our department fill out a progress report that is evaluated by the graduate advisors. We want to make this online. After we told this to our IT manager, he said OK, let s have a meeting so that you can explain us the functionality you want. We scheduled a meeting and at the meeting we went over The questions that should be in the progress report Type of answers for each question (is it a text field, a date, a number, etc?) What type of users will access this system (students, faculty, staff)? What will be the functionality available to each user?
3 Requirements Analysis and Specification Meeting where we discussed the functionality, input and output formats, types of users, etc. is called requirements analysis during requirements analysis software developers try to figure out the functionality required by the client After the requirements analysis all these issues can be clarified in a Software Requirements Specification (SRS) document maybe the IT folks who attended the requirements analysis meeting are not the ones who will develop the software, so the software developers will need a specification of what they are supposed to build. Writing precise requirements specifications can be challenging: formal (mathematical) specifications are precise, but hard to read and write English is easy to read and write, but ambiguous
4 Design After figuring out the requirements specifications, we have to build the software In our example, we assume that the IT folks are going to talk about the structure of this application first there will be a backend database, the users will first login using an authorization module, etc.
5 Design Deciding on how to modularize the software is part of the architectural design it is helpful (most of the time necessary, since one may be working in a team) to document the design architecture (i.e., modules and their interfaces) before starting the implementation After figuring out the modules, the next step is to figure out how to build those modules Detailed design involves writing a detailed description of the processing that will be done in each module before implementing it generally written in some structured pseudo-code
6 Implementation and Testing Finally, the IT folks are going to pick an implementation language (PHP, Java Servlets, etc) and start writing code This is the implementation phase implement the modules defined by the architectural design and the detailed design. After the implementation is finished the IT folks will need to check if the software does what it is supposed to do Use a set of inputs to test the program when are they done with testing? can they test parts of the program in isolation?
7 Maintenance After they finished the implementation, tested it, fixed all the bugs, are they done? No, we (client) may say, I would like to add a new question to the PhD progress report or I found a bug when I was using it or You know, it would be nice if we can also do the MS progress reports online etc. The difficulty of changing the program may depend on how we designed and implemented it This is called the maintenance phase where the software is continually modified to adopt to the changing needs of the customer and the environment.
8 Software Process Models Software process (software life-cycle) models Determine the stages (and their order) involved in software development and evolution Establish the transition criteria for progressing from one stage to the next Software process models answer the questions: What shall we do next? How long shall we continue to do it?
9 Waterfall Model requirements analysis and specification design The waterfall model implementation testing and integration maintenance Software product is not only the executable file: source code, test data, user manual, requirements specification, design specification
10 Waterfall Model Waterfall model is document-driven Documents requirements specification, design specification, test-plan these documents are crucial in achieving maintainability, traceability and visibility Feedback loops between different stages are confined to successive stages to minimize the expensive rework involved in feedback across many stages
11 Waterfall Model Problems with waterfall model Because of the restricted feedback loops, waterfall model is essentially sequential for example, the requirements have to be stated completely before the implementation starts. it is often difficult for the customer to state all requirements explicitly it is hard to handle changes in the requirements A working model of the software is not available until late in the project life-span an undetected mistake can be very costly to fix the delivered program may not meet the customer s needs For interactive, end-user applications document-driven approach may not be suitable. for example, it is hard to document a GUI
12 Rapid Prototyping After an initial requirements analysis, a quick design is developed This quick design should focus on aspects of the software that will be visible to the user such as input/output formats The quick design is used to construct a prototype The prototype is reviewed by the customer and/or user to refine the requirements for the software to be developed Prototype serves as a mechanism for identifying software requirements Especially useful for interactive applications
13 Dangers of prototyping Rapid Prototyping The quick and possibly poor choices made in the design and the implementation of the prototype may influence the real product After seeing a prototype customer may demand a working product fast The prototype becomes the requirements specification. Since requirements specification serves as a contract between customer and developer, a prototype may not be a good contract
14 Spiral Model Determine objectives, alternatives, constraints cumulative cost start progress in each cycle Evaluate alternatives, identify, resolve risks Plan next phase radial dimension shows the cumulative cost angular dimension shows the progress in each cycle Develop, verify next-level product
15 Spiral Model Spiral model consists of iterative cycles Spiral model can be considered a generalization of other process models Each cycle consists of four steps: Step 1 Identify the objectives (for example: performance, functionality, ability to accommodate change) Identify the alternative means of implementing this portion of the product (for example: different designs, reuse, buy) Identify the constraints imposed on the application of the alternatives (for example: cost, schedule)
16 Spiral Model Step 2 Evaluate the alternatives relative to objectives and constraints. Evaluate the risks involved with each alternative Resolve the risks using prototyping, simulation, benchmarking, requirements analysis, etc. alternative: write a requirements specification risk: customer may not be able to articulate the requirements precisely which may end up a costly redevelopment effort risk resolution: develop a rapid prototype
17 Spiral Model Step 3 Develop and verify the product Product could be the software requirements specification, the design specification, etc. Step 4 Plan the next phase Depending on the next-phase this could be a requirements plan, an integration and test plan, etc.
18 Spiral Model The basic idea in spiral model is to evaluate and resolve risks at every step of the development Based on the risks involved in the development spiral model may become equivalent to other models (or a mixture of them) If a project has a low risk in user-interface and performance requirements and has a high risk in budget and schedule predictability and control, based on these risks spiral model may turn into the waterfall model The challenges in using the spiral model relies on risk assessment expertise steps of the software life-cycle are not clearly defined
19 How Microsoft Builds Software M. A. Cusumano and R. W. Selby, Communications of the ACM, 1997 Microsoft 1996 numbers big company 20,500 employees (2010: 80-90K) 250 products $8.7 billion in revenues big products (2010: $62 billon) Windows 95: more than 11 million lines of code, a development team of 200 programmers and testers Windows 7: 50+ million lines, 25 feature teams, 40 developers each
20 How Microsoft Builds Software M. A. Cusumano and R. W. Selby, Communications of the ACM, 1997 Microsoft philosophy for product development: to cultivate its roots as a highly flexible entrepreneurial company do not adopt too many of the structured software-engineering practices scale up the loosely structured (hacker) style of development
21 Challenges for Microsoft Large complex software products Cannot be built by 2-3 person teams Team members need to create components that are interdependent Sequential life-cycle models such as waterfall model does not work very well It is hard to define components accurately in the early stages of the development cycle Requirements evolve during the development process
22 Microsoft s approach: Microsoft s Approach Small parallel teams (three to eight developers each) or individual programmers Individual programmers and teams have freedom to evolve their designs and operate nearly autonomously Teams synchronize their changes frequently to make sure that the product components all work together
23 Synch-and-Stabilize Approach Continually synchronize what people are doing as individuals and as members of parallel teams and periodically stabilize the product in increments milestone, daily build, nightly build, zero-defect Build: putting together partially completed pieces of a software product during the development process to see what functions work and what problems exist, usually by completely recompiling the source code and executing automated regression tests
24 Synch-and-Stabilize Approach Three phases Planning Phase: Define product vision, specification and schedule Development Phase: Feature development in 3 or 4 sequential subprojects that each results in a milestone release Stabilization Phase: Comprehensive internal and external testing after each milestone, final product stabilization and ship
25 Planning Phase Planning Phase Vision Statement: product managers (marketing specialists) and program managers (who specialize in writing functional specifications) use extensive customer input to identify priorityorder product features Specification Document: Based on the vision statement, program management and development group define feature functionality, architectural issues, and component interdependencies Schedule and Feature Team Formation: Based on the specification document, program management coordinates schedule and arranges feature teams that each contain approximately 1 program manager, 3-8 developers and 3-8 testers (testers work in parallel, 1:1 with developers) Experience shows that initial feature set may change up to 30%
26 Development Phase Development Phase Program managers coordinate the evolution of the specification. Developers design, code, and debug. Testers pair with developers for continuous testing Milestone 1: First 1/3 of features (Most critical features and shared components Milestone 2: Second 1/3 of features Milestone 3: Final 1/3 of features (Least critical features) All the feature teams go through a complete cycle of development, feature integration, testing and fixing problems in each milestone Throughout the project the feature teams synchronize their work by building the product and by finding and fixing errors on a daily and weekly basis At the end of a milestone the developers fix almost all the errors detected and stabilize the product
27 Development Phase: Milestones Milestone 1 (first 1/3 features) Development (design, coding, prototyping) Usability lab Private release testing Daily builds Feature debugging Feature integration Code stabilization Buffer time (20-50%) Milestone 2 (next 1/3 of the features) Development Usability lab Private release testing Daily builds Feature Debugging Feature Integration Code stabilization Buffer time Milestone 3 (last set) Development Usability lab Private release testing Daily builds Feature Debugging Feature Integration Feature Complete Code Complete Code stabilization Buffer time Zero-defect release Release to Manufacturing
28 Stabilization Phase Stabilization Phase Program managers coordinate with OEMs (Original Equipment Manufacturers) and ISVs (Independent Software Vendors) and monitor customer feedback. Developers perform final debugging and code stabilization. Testers recreate and isolate errors Internal testing: Thorough testing of complete product External testing: Thorough testing of complete product outside of company by beta sites such as OEMs or ISVs and end users Release preparation: Prepare final release of golden master disk and documentation for manufacturing
29 Synch-and-Stabilize Approach: Requirements Vision statement and feature specifications to guide projects leaves developers and program managers room to innovate or adapt to changed or unforeseen competitive opportunities and threats Base feature selection and priority order on user activities and data Particularly for end-user applications there is a need for continuous observation and testing by real users during development
30 Synch-and-Stabilize Approach: Project Management Divide large projects into multiple milestone cycles with buffer time (20-50% of total project time) and no separate product maintenance group buffer times give people time to respond to changes and unexpected difficulties and delays Control by individual commitments to small tasks and fixed project resources Managers allow team members to set their own schedules but only after the developers have analyzed tasks in detail (for example halfday to three-day chunks). Team members are asked to personally commit to the schedules they set. Managers then fix project resources by limiting the number of people they allocate to each project, they also try to limit the time spent on projects (teams can sometimes delete features if they fall too far behind)
31 Synch-and-Stabilize Approach: Design Evolve a modular design architecture mirroring the product structure in the project structure Modular architecture allows teams to incrementally add or combine features
32 Synch-and-Stabilize Approach: Implementation Work in parallel teams but synch up and debug daily Developers can check-out private copies of source code files from a centralized master version of the source code. Developers implement their features by changing the private copies of the source code files. Developers create private build of the product containing the new feature and test it Then they check-in their private copy of the source code to the master version. Check-in process includes an automated regression test to make sure that there are no new errors. Developers typically check-in their code twice a week Always have a product you can ship versions for every major platform and market designated developer (project build master) generates a complete build of the product on a daily basis
33 Synch-and-Stabilize Approach: Testing/Debugging Speak a common language on a single development site Nearly all teams work on the same physical site with common development languages (C, C++) common coding styles, and standardized development tools Continuously test the product as you build it Product teams test the product as they build them including usability tests on users Metric data to determine milestone completion and product release By monitoring metrics such as how many bugs are newly opened, resolved, fixed, and active, the managers decide when to move forward in the project
34 Synch-and-Stabilize Approach: Summary Summary of Microsoft s approach Small parallel teams (three to eight developers each) which have freedom to evolve their designs and operate nearly autonomously Daily synchronization through product builds, periodic milestone stabilization, and continuous testing Coordinates teams in a flexible manner Suitable for fast changing demands
35 Sync-and-Stabilize vs. Waterfall Sync-and-Stabilize Process Model (Evolutionary Development) Product development and testing done in parallel Vision statement and evolving specification Features are prioritized and built in 3 or 4 milestone subprojects Frequent synchronizations (daily builds) and intermediate stabilizations (milestones) Fixed release and ship dates and multiple release cycles Customer feedback continuous in the development process Product and process is designed so that large teams work like small teams Waterfall Process Model (Sequential Development) Separate phases done in sequence Complete frozen specification and detailed design before building the product Trying to build all pieces of a product simultaneously One late and large integration and system test phase at the project s end Aiming for feature and product perfection in each project cycle Feedback primarily after development as inputs for future projects Working primarily as a large group of individuals in a separate functional department
36 Evolutionary Software Development Software is built iteratively and incrementally by first providing an initial version and then improving/extending it based on the user feedback until an adequate system has been developed Scrum, extreme programming, agile software development As opposed to the sequential nature of the waterfall model, in the evolutionary software development specification, development and validation activities are executed concurrently with fast feedback among these activities specification initial version outline description development intermediate versions validation final version
37 Agile Software Development Manifesto for Agile Software Development available at: We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more
38 Principles of Agile Software Development Our 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. Business people and developers must work together daily throughout the project. 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.
39 Principles of Agile Software Development Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity -- the art of maximizing the amount of work not done -- is essential. The best architectures, requirements, and designs emerge from selforganizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
40 Extreme Programming Extreme programming (XP) is a type of agile software development process proposed by Kent Beck Embracing Change with Extreme Programming, by Kent Beck, IEEE Computer, October 1999, pp
41 Extreme Programming XP follows the agile software development principles as follows Software is built iteratively, with frequent releases Each release implements the set of most valuable features/usecases/stories that are chosen by the customer Each release is implemented in a series of iterations, each iteration adds more features/use-cases/stories Programmers turn the stories into smaller-grained tasks, which they individually accept responsibility for The programmer turns a task into a set of test cases that will demonstrate that the task is finished Working as pairs, the programmers make the test cases run, evolving the design in the meantime to maintain the simplest possible design for the system as a whole
42 Extreme Programming Practices Planning: Customers decide the scope and timing of releases based on the estimates provided by programmers. Programmers implement only the functionality demanded by the features/use-cases/stories in that iteration. Small Releases: The system is put into production in a few months, before solving the whole problem. New releases are made often anywhere from daily to monthly Simple Design: At every moment, the design runs all the tests, communicates everything the programmers want to communicate, contains no duplicate code, and has the fewest possible classes and methods.
43 Extreme Programming Practices Tests: Programmers write unit tests minute by minute. These tests are collected and they must all run correctly. Customers write functional tests for the features/use-cases/stories in an iteration. Refactoring: The design of the system is evolved through transformations of the existing design that keep all the tests running. Pair programming: All production code is written by pairs of programmers, each pair uses a single computer. Continuous integration: New code is integrated with the current system after no more than a few hours.
44 Extreme Programming Practices Collective ownership: Every programmer improves any code anywhere in the system at any time if they see the opportunity. On-site customer: A customer sits with the team full-time. Open workspace: The team works in a large room with small cubicles around the periphery. Pair programmers work on computers set up in the center.
45 Scrum An evolutionary/iterative/incremental/agile software process The main roles in Scrum are: Scrum team: Team of software developers Scrum master : Project manager Product owner: Client Characteristics of Scrum: Self-organizing teams Product development in two to four week sprints Requirements are captures as items in a list of product backlog
46 Scrum Overview
47 Scrum Roles Product owner Defines the features of the product Decides on release date and content Prioritize features according to market value Adjust features and priority every iteration as needed Accepts or rejects work results Scrum Master Represents management of the project Responsible for following the Scrum process Ensures that the team is fully functional and productive Shields the team from external influences
48 Scrum Roles Scrum Team Typically 5 to 9 people Cross-functional team that does the software development including designing, programming and testing Co-location and verbal communication among team members Teams are self-organizing, no titles Team membership should not change during a sprint
49 Scrum Meetings Sprint Planning (at most 8 hours) This is done at the beginning of every sprint cycle (2 to 4 weeks) Team selects items from the product backlog they can commit to completing Sprint backlog is created Tasks for this sprint are identified and each is estimated (1 to 16 hours). This is done collaboratively, not by ScrumMaster High-level design is discussed Daily Scrum (at most 15 minutes) Daily, stand-up meeting Not for problem solving Every team member answers three questions: What did you do yesterday? What will you do today? Is anything in your way? (ScrumMaster is responsible for following up and resolving the impediments)
50 Scrum Meetings Sprint Review (at most 4 hours) Team presents what it accomplished during the sprint Typically a demo of new features or underlying architecture Incomplete work should not be demonstrated Informal meeting, no slides Whole team participates Open to everybody
51 Scrum Meetings Sprint Retrospective (at most 3 hours) Periodically take a look at what is and is not working Done after every sprint ScrumMaster, Product owner, Team and possibly customers and others can participate One way of doing sprint retrospective is to ask everyone what they would like to 1) Start doing, 2) Stop doing, 3) Continue doing
52 Scrum Artifacts Product Backlog These are the requirements A list of all desired work on the project Prioritized by the product owner Reprioritized at the start of each sprint Each backlog item also has an estimated time it will take to complete it
53 Scrum Artifacts Sprint Backlog Team members sign up for work of their own choosing Estimated work remaining is updated daily Any team member can add, delete or change the sprint backlog Each sprint backlog item has daily estimates for the amount of time that will be spent on that item each day Burn Down Chart A daily updated chart displaying the remaining cumulative work on the sprint backlog. It gives a simple view of the sprint progress.
54 More on Scrum More information about Scrum process is available at:
Life Cycle Models V. Paúl Pauca Department of Computer Science Wake Forest University CSC 331-631 Fall 2013 Software Life Cycle The overall framework in which software is conceived, developed, and maintained.
Agile Project Management By Mark C. Layton Agile project management focuses on continuous improvement, scope flexibility, team input, and delivering essential quality products. Agile project management
Presented by Jennifer Bleen, PMP Project Services Practice of Cardinal Solutions Group, Inc. Contact: Agile Manifesto We are uncovering better ways of developing software by doing it and helping others
Agile Project Management with Scrum Resource links http://www.agilealliance.org/ http://www.agilemanifesto.org/ http://www.scrum-master.com/ 1 Manifesto for Agile Software Development Individuals and interactions
AGILE HANDBOOK OVERVIEW WHAT IS THIS? This handbook is meant to be a quick-starter guide to Agile Project Management. It is meant for the following people: Someone who is looking for a quick overview on
CSE 435 Software Engineering Sept 16, 2015 2.1 The Meaning of Process A process: a series of steps involving activities, constraints, and resources that produce an intended output of some kind A process
Agile Scrum Workshop What is agile and scrum? Agile meaning: Able to move quickly and easily. Scrum meaning: a Rugby play Agile Scrum: It is an iterative and incremental agile software development framework
Software Development Life Cycle (SDLC) Supriyo Bhattacharjee MOF Capability Maturity Model (CMM) A bench-mark for measuring the maturity of an organization s software process CMM defines 5 levels of process
Introduction to Agile Software Development Word Association Write down the first word or phrase that pops in your head when you hear: Extreme Programming (XP) Team (or Personal) Software Process (TSP/PSP)
Agile Development with C# Paweł Jarosz, email@example.com Cracow University of Technology, Poland Jyvaskyla University of Applied Sciences, February 2009 Paweł Jarosz who am I? M.Sc. of Applied Physics
Journal of Software Engineering and Applications, 2013, 6, 59-64 http://dx.doi.org/10.4236/jsea.2013.62010 Published Online February 2013 (http://www.scirp.org/journal/jsea) 59 Case Study on Critical Success
Introduction to Agile Scrum by Julia M. Lobur Penn State Harrisburg CMPSC 487W Fall 2015 Introduction to Scrum Learning Goals Relationship of Scrum to other Agile methods Scrum Framework Scrum Roles Scrum
SATORI CONSULTING LEAN AGILE POCKET GUIDE Software Product Development Methodology Reference Guide PURPOSE This pocket guide serves as a reference to a family of lean agile software development methodologies
Scaling Scrum Colin Bird & Rachel Davies Scrum Gathering London 2007 Scrum on a Slide Does Scrum Scale? Ok, so Scrum is great for a small team but what happens when you have to work on a big project? Large
Agile Beyond The Team 1 Dilbert Agile 2 What Does Your Organization Value? Projects over Teams? Do new teams spools up for new projects? On-Time/On-Budget Delivery over Zero Maintenance Products Deliver
Software Development Life Cycle (SDLC) and Development Methods There are some enterprises in which a careful disorderliness is the true method. Herman Melville Capability Maturity Model (CMM) A Capability
Agent and Object Technology Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma Advanced Software Engineering Software Development Processes Prof. Agostino Poggi Software Development
Agile methods CMSC435-1 Objectives To explain how an iterative, incremental development process leads to faster delivery of more useful software To discuss the essence of agile development methods To explain
D25-2 Agile and Scrum Introduction How to Use this Download This download is an overview of a discussion Intertech has with clients on Agile/Scrum This download has an overview of Agile, an overview of
The Agile Manifesto is based on 12 principles: Customer satisfaction by rapid delivery of a useful product solution Welcome changing requirements, even late in development Working products are delivered
EXTREME PROGRAMMING AGILE METHOD USED IN PROJECT MANAGEMENT Cruceru Anca Romanian- American University, Faculty of Management- Marketing, 1B Expozitiei Blvd, Bucharest, firstname.lastname@example.org, 0723508894
Software Process in Modern Software Development Lecture 3 Software Engineering i Practice Software engineering practice is a broad array of principles, concepts, methods, and tools that must be considered
Software Engineering and Scientific Computing Barbara Paech, Hanna Valtokari Institute of Computer Science Im Neuenheimer Feld 326 69120 Heidelberg, Germany http://se.ifi.uni-heidelberg.de email@example.com
Agile-Waterfall Hybrid Jessica LaGoy, MS, PMP About Jess BS Applied Physics, WPI / MS Cybersecurity, UMUC PMP, ITIL, Data Scientist, Tableau, Alteryx Project Experience Data and technology Construction
Neglecting Agile Principles and Practices: A Case Study Patrícia Vilain Departament de Informatics and Statistics (INE) Federal University of Santa Catarina Florianópolis, Brazil firstname.lastname@example.org Alexandre
A Cynical View on Agile Software Development from the Perspective of a new Small-Scale Software Industry Apoorva Mishra Computer Science & Engineering C.S.I.T, Durg, India Deepty Dubey Computer Science
Agile Development Methods: Philosophy and Practice CPSC 315 Programming Studio Fall 2010 History of Agile Methods Particularly in 1990s, some developers reacted against traditional heavyweight software
Adapting Agile Software Development to Regulated Industry Paul Buckley Section 706 Section Event June 16, 2015 Agenda FDA s expectations for Software Development What is Agile development? Aligning Agile
Capstone Agile Model (CAM) Capstone Agile Model (CAM) Approach Everything we do within the Capstone Agile Model promotes a disciplined project leadership process that encourages frequent inspection and
Waterfall to Agile DFI Case Study By Nick Van, PMP DFI Case Study Waterfall Agile DFI and Waterfall Choosing Agile Managing Change Lessons Learned, Sprints Summary Q and A Waterfall Waterfall Waterfall
www. TSG Quick Reference Guide to Agile Development & Testing Enabling Successful Business Outcomes What is Agile Development? There are various opinions on what defines agile development, but most would
Ingegneria del Software Corso di Laurea in Informatica per il Management Agile software development Davide Rossi Dipartimento di Informatica Università di Bologna The problem Efficiency: too much effort
USCIS/SPAS: Product Backlog Items and User Stories 4/16/2015 Dr. Patrick McConnell July 9, 2015 1 First, an old joke.. I can t identify an original source for this cartoon. As best as I can tell, the art
How to manage agile development? Rose Pruyne Jack Reed What will we cover? Introductions Overview and principles User story exercise Retrospective exercise Getting started Q&A About me: Jack Reed Geospatial
An Ideal Process Model for Agile Methods Marcello Visconti 1 and Curtis R. Cook 2 1 Departamento de Informática, Universidad Técnica Federico Santa María, Valparaíso, CHILE email@example.com 2 Computer
Processes in Software Development Presented 11.3.2008 by Lars Yde, M.Sc., at Selected Topics in Software Development, DIKU spring semester 2008 Software hall of shame Classic mistakes ACM Code of Ethics
Agile QA s Revolutionary Impact on Project Management Introduction & Agenda Rachele Maurer Agile Coach, Platinum Edge Inc. PMP, CSM, PMI-ACP Agenda A quick overview of agile Current QA practices QA using
XP & Scrum Beatrice Åkerblom firstname.lastname@example.org extreme Programming XP Roles XP Roles, cont!d! Customer ~ Writes User Stories and specifies Functional Tests ~ Sets priorities, explains stories ~ May or
Adopting Agile Project Management - Corporate Culture Must Match (Apr 15) by Megan Torrance April 20, 2015 If you re contemplating adopting an agile approach, and the thought of implementing new project
EuroSTAR 2011 Agile on huge banking mainframe legacy systems. Is it possible? Christian Bendix Kjær Hansen Test Manager November 22, 2011 What is this presentation about? Goal Inspire others working with
Jukka Mannila KEY PERFORFORMANCE INDICATORS IN AGILE SOFTWARE DEVELOPMENT Information Technology 2013 KEY PERFORFORMANCE INDICATORS IN AGILE SOFTWARE DEVELOPMENT Mannila, Jukka Satakunnan ammattikorkeakoulu,
The Basics of Scrum An introduction to the framework Introduction Scrum, the most widely practiced Agile process, has been successfully used in software development for the last 20 years. While Scrum has
A Viable Systems Engineering Approach Presented by: Dick Carlson (email@example.com) Philip Matuzic (firstname.lastname@example.org) i i Introduction This presentation ti addresses systems engineering
An Introduction to Agile Software Development June 2007 Table of Contents Executive summary... 3 Agile vs. waterfall: practical differences in methodology... 4 Two agile software development methodologies...
Comparing Scrum And CMMI How Can They Work Together Neil Potter The Process Group email@example.com 1 Agenda Definition of Scrum Agile Principles Definition of CMMI Similarities and Differences CMMI
Génie Logiciel et Gestion de Projets Software Processes Focus on Extreme Programming 1 Roadmap Process, Method, Methodology?? What is a software process? Software Process Models Methodologies: RUP Focus
So l u t i o n s Blending Agile and Lean Thinking for More Efficient IT Development By Harry Kenworthy Agile development and Lean management can lead to more cost-effective, timely production of information
ASSESSMENT OF SOFTWARE PROCESS MODELS Akhilesh Research Scholar, Department of Computer Science, Manav Bharti University, Solan (H.P.) ABSTRACT The field of software engineering is related to the development
Agile Processes and Distributed Projects: Dream or Nightmare? Instructor: Kevin Thompson, Ph.D., PMP, ACP, CSP 4100 E. Third Ave, Suite 205, Foster City, CA 94404 650-931-1651 www.cprime.com The leader
ECE155: Engineering Design with Embedded Systems Winter 2013 Lecture 21 March 7, 2013 Patrick Lam version 1 Software Development Lifecycle If you re asked to develop a software project, you re likely to
AGILE - QUICK GUIDE http://www.tutorialspoint.com/agile/agile_quick_guide.htm Copyright tutorialspoint.com AGILE - PRIMER Agile is a software development methodology to build a software incrementally using
www.ijcsi.org 457 Agile-Fall Process Flow Model A Right Candidate for Implementation in Software Development and Testing Processes for Software Organizations Prakash.V SenthilAnand.N Bhavani.R Assistant
YOUR SUCCESS IS OUR FOCUS Whitepaper Published on: Jun-09 Author: Ramesh & Lakshmi Narasimhan 2009 Hexaware Technologies. All rights reserved. Table of Contents 1. Introduction 2. Subject Clarity 3. Agile
SE464/CS446/ECE452 Software Life-Cycle and Process Models Instructor: Krzysztof Czarnecki 1 Some of these slides are based on: Lecture slides by Ian Summerville accompanying his classic textbook software
Rapid software development Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 17 Slide 1 Objectives To explain how an iterative, incremental development process leads to faster delivery of
International Association of Scientific Innovation and Research (IASIR) (An Association Unifying the Sciences, Engineering, and Applied Research) International Journal of Engineering, Business and Enterprise
Extreme Programming, an agile software development process Paul Jackson School of Informatics University of Edinburgh Recall: Waterfall and Spiral Models Waterfall: Spiral: Split project into controlled
Agile Software Development Application in the Medical Device Industry Kelly Weyrauch Medtronic, Inc. (29 April 2008) Introduction Purpose Provide an introduction to Agile Software Development as it applies
Process Methodology for Wegmans Deli Kiosk Version 1.0 Prepared by DELI-cious Developers Rochester Institute of Technology September 15, 2013 1 Table of Contents 1. Process... 3 1.1 Choice... 3 1.2 Description...
Master thesis in Applied Information Technology REPORT NO. 2008:014 ISSN: 1651-4769 Department of Applied Information Technology or Department of Computer Science Bottlenecks in Agile Software Development
Agile Requirements Generation Model: A Soft-structured Approach to Agile Requirements Engineering Shvetha Soundararajan Thesis submitted to the faculty of the Virginia Polytechnic Institute and State University
Introduction to Agile Software Development EECS 690 Agile Software Development Agenda Research Consent Forms Problem with Software Engineering Motivation for Agile Methods Agile Manifesto Principles into
Overview This is a 15-day live facilitator-led or virtual workshop is designed to prompt your entire team to work efficiently with Microsoft s Application Lifecycle Management solution based around Visual
Agile Project Management: Adapting project behaviors to the software development environment with Bill Doescher, PMP, CSM PrincipalConsultant and Product Development Director Business Management Consultants
Extreme Programming, an agile software development process Nigel Goddard School of Informatics University of Edinburgh Recall: Waterfall and Spiral Models Waterfall: Spiral: Split project into controlled
Agile with XP and Scrum Amit Goel National Agile Software Workshop @ Indore Agile India Conference Agile Software Community of India Disclaimer and Credits Most of material in this presentation has been
SCRUM AT RIIS A Standish study found that only 20% of features in a typical system were used often or always and 45% of features were never used at all. The ability to embrace change is critical to reducing
Agile and Secure: Can We Be Both? OWASP AppSec Seattle Oct 2006 Keith Landrus Director of Technology Denim Group Ltd. firstname.lastname@example.org (210) 572-4400 Copyright 2006 - The OWASP Foundation Permission
Getting Agile with Scrum Mike Cohn Mountain Goat Software email@example.com 1 Mike Cohn - background 2 We re losing the relay race The relay race approach to product development may conflict
Agile Software Development Methodologies and Its Quality Assurance Aslin Jenila.P.S Assistant Professor, Hindustan University, Chennai Abstract: Agility, with regard to software development, can be expressed
Software Engineering An Introduction Fakhar Lodhi 1 Engineering The science concerned with putting scientific knowledge to practical use. Webster s Dictionary Physics versus Electrical Engineering 2 Software
Today: Software Development Models (cont) CPSC 491 Development Processes (aka Development Lifecycle) Define the steps, and their order, to be carried out The main steps (or phases) generally include: 1.
Agile Notetaker & Scrum Reference Designed by Axosoft, the creators of OnTime the #1 selling scrum software. Scrum Diagram: Team Roles: roduct Owner: Is responsible for what goes into the product backlog
Scrum SE Presentation by Anurag Dodeja Spring 2010 What is Scrum? Scrum is an agile software development framework. Work is structured in cycles of work called sprints, iterations of work that are typically
Life-Cycle Model Software Life-Cycle Models Xiaojun Qi It specifies the various phases/workflows of the software process, such as the requirements, analysis (specification), design, implementation, and
How Silk Central brings flexibility to agile development The name agile development is perhaps slightly misleading as it is by its very nature, a carefully structured environment of rigorous procedures.
PROCESS OF MOVING FROM WATERFALL TO AGILE PROJECT MANAGEMENT MODEL Sanja Vukićević 1, Dražen Drašković 2 1 Faculty of Organizational Sciences, University of Belgrade, firstname.lastname@example.org 2 Faculty