SOFTWARE DEVELOPMENT METHODOLOGIES Prof dr Angelina Njegu PRESENTATION

SOFTWARE DEVELOPMENT METHODOLOGIES Prof. dr Angelina Njeguš

PRESENTATION OVERVIEW • What is a software development methodology? • Why do we use software development methodologies? • Software Development Methodologies • Traditional vs Agile methodologies • MSF » MSF for Agile • RUP » Open Unified Process • SCRUM

WHAT IS SOFTWARE DEVELOPMENT METHODOLOGY? • The software development methodology (SDM) emerged in 1960 s. • SDM is used to structure, plan, and control the process of software system development. • The systems development life cycle (SDLC) is considered to be the oldest formalized methodology.

• Most organizations today (such as IBM, Microsoft, SAP, NASA. . . ) use a specific type of methodology that is tailored to their needs. • Why using methodologies? • Provides a consistent approach • Reduces the risk of errors WHY DO WE USE SDM? • Issues complete and consistent documentation for current and future projects • Delivers quality software that can be easily changed • The best practices of system development are used • Due to the fact that the project teams change, it allows those teams who continue to work, quickly and easily understand the results of the work • Easier changes are made over models than in source code

SDM TYPE S

WATERFALL MODEL • Considered as traditional software development method. • WM is rigid linear model that consists of sequential phases (requirements, design, implementation, verification, maintenance) in which distinct goals are accomplished. • Each phase must be 100% complete before the next phase can start, and traditionally there is no process for going back to modify the project or direction.

DRAWBACKS • Waterfall approach can not adequately handle the increasing complexity that arises: • not applicable for maintenance projects • not excellent for long and ongoing projects • large or distributed teams • does not allow identification and mitigation of risks in the early stages of the project (Fig. ) • This "inflexibility" in a pure waterfall model has been a source of criticism.

WATERF ALL MODEL

ITERATIVE INCREMENTAL MODEL • Iterative development was created as a response to inefficiencies and problems found in the waterfall model. • The basic idea behind this method is to develop a system through repeated cycles (iterative) and in smaller portions at a time (incremental), allowing software developers to take advantage of what was learned during development of earlier parts or versions of the system. • At each iteration, design modifications are made and new functional capabilities are added.

SPIRAL MODEL • The Spiral Model is a sophisticated model that focuses on early identification and reduction of project risks. • In this software development methodology, developers: start on a small scale then explores the risks involved in the project, make a plan to handle the risks decide whether to take the next step of the project to do the next iteration of the spiral.

• Rapid Application Development (RAD) is an effective methodology to provide much quicker development and higher-quality results than those achieved with the other software development methodologies. • The main objective of this methodology is to accelerate the entire software development process. RAPID APPLICATION DEVELOPMENT • The goal is easily achievable because it allows active user participation in the development process. The user design and construction phases repeat until the user confirms that the product meets all requirements.

DYNAMIC SYSTEMS DEVELOPMENT MODEL • Dynamic Systems Development Model is a software development methodology originally based on the Rapid Application Development methodology. • This is an iterative and incremental approach that emphasizes continuous user involvement. • Its main aim is to deliver software systems on time and on the budget. • This model simply works on the philosophy that nothing is developed perfectly in the first attempt and considers as an ever-changing process.

WATERFALL MODEL VS ITERATIVE- INCREMENT

AGILE METHODOLOGY • In 2001, seventeen software developers met in Utah to discuss lightweight development methods • They published the Manifesto for Agile Software Development.

TRADITIONAL VS AGILE APPROACH

MICROSOFT SOLUTION FRAMEWORK § § § Traditional MSF Framework vs Methodology Risk Management MSF team model Project Management MSF software development processes

MSF VERSIONS MSFv 3 Essentials MSFv 4 Essentials Discipline MSFv 5 Essentials Application Development MSF for Agile Software Development Infrastructure MSF for CMMI® Process Improvement Family Product

1 st Avenue Orange Street Plum Street FRAMEWORK VS METHODOLOGY 2 nd Avenue 3 rd Avenue . N. . W . . Smith River . . 4 th Avenue E S MSF

MSF SOFTWARE DEVELOPMENT DISCIPLINES Team management MSF Risk Management Software Process Management

RISK MANAGEMENT Risk element Description Identify risk List of potential risks and their triggers Probability of risk occurrence Estimate of probability that this risk will materialize (1 – 100%) Severity The intensity of undesirable impact to the project—if the risk materializes. Estimate the impact of the risk in %. The overall threat porobability * severity = threat A higher-severity risk with high probability has higher relative priority. Risk planning Risk avoidance or minimization strategies Action The contingent response if the risk materializes. Owner Person who monitors the risk and takes action if necessary.

MSF TEAM MODEL Product Managemen t User Experience Program Managemen t Release Managemen t Developmen t Testing

MSF SOFTWARE PROCESS DEVELOPMENT

SOFTWARE DEVELOPMENT METHODOLOGIES Waterfall models Agile methods Iterative incremental models (Scrum, XP, Open UP, (Spiral, RAD, RUP. . . ) Crystal, Lean, DSDM, Agile MSF. . . )

RATIONAL UNIFIED PROCESS § Unified process § RUP development phases § Best practices

UNIFIED PROCESS • Unified process was an attempt to bring together the best of the notations and software design approaches that have been formulated by Jacobson, Booch, Rumbaugh • Since the UP is developed and maintained by the company Rational, the title is Rational Unified Process - RUP • RUP is UML based. Dr Ivar Jacobson • Component architecture • Use cases • UML & RUP Grady Booch • Leader in object oriented analysis and design • UML development James Rumbaugh • Creator of object modeling (OMT) and UML

RATIONAL UNIFIED PROCESS RUP is a use-case-driven, architecture-centric, iterative and incremental development process • RUP divides the project into four phases: 1. Inception 2. Elaboration 3. Construction 4. Transition

ITERATIVE SOFTWARE DEVELOPMENT Inception: What to develop • Vision • Higher level use cases • Risk identification • Evaluation of the costs, time, plan, and software quality Elaboration: How to develop • Basic architecture • Requirement analysis • Estimation of the resources, and time Construction Transition • Software development • Solution validation

MILESTONES

SCRUM

What is the purpose of To bring order to the chaos of a live ball on the a Rugby field when no team has possession yet. Scrum? What is the purpose of Scrum Development ? To bring order to the chaos of a development project. Requirements will often change, so Scrum uses sprints to speed through known requirements, while also being able to quicly adapt to project changes.

THE F OUNDI NG OF S CRUM • In 1995 the first public presentation by Ken Schwaber (right) i Jeff Sutherland (left) • In 2001. godine – the first book Agile Software Development with Scrum by Ken Schwaber and Mike Beedle. 31

WHAT IS SCRUM? • Scrum is an agile project management framework used primarily for software development projects with the goal of delivering new software capability every 2 -4 weeks.

USAGE OF FEATURES IN TYPICAL SYSTEMS Always Often Sometimes Rarely Never used

SCRUM FRAME WORK

SCRUM FRAMEWORK - ROLES

SCRUM ROLES • Product Owner • Possibly a Product Manager or Project Sponsor • Decides features, release date, prioritization, $$$ • Scrum Master • Typically a Project Manager or Team Leader • Responsible for enacting Scrum values and practices • Remove impediments / politics, keeps everyone productive • Project Team • 5 -10 members; Teams are self-organizing • Cross-functional: QA, Programmers, UI Designers, etc. • Membership should change only between sprints

PRODUCT OWNER • The voice of the customer, represents the internal stakeholders, and is responsible for delivering the highest possible value to the business. § Creates and communicates the vision, strategy and roadmap § Generates a high-level release plan § Forms the product backlog containing all of the work to be performed § Collaborates with the team to develop and deliver the work § Works with customers to review releases and adjust development accordingly § Actively supports the business with progress updates and metrics

SCRUM MASTER The Scrum Master serves the Product Owner: • Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team • Finding techniques for effective Product Backlog management. • Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value. • Understanding and practicing agility. . . The Scrum Master serves the Development Team in several ways: • Coaching the Development Team • Helping the Development Team to create high-value products. • Protects the team from external interference. . .

SCRUM DEVELOPMENT TEAM • Team members share the same norms and rules • The Scrum Team is self organizing • From 5 to 9 people - cross-team: developers, testers, designers. . . • A Scrum Team is small and has no sub-teams • The people within the Scrum Team work full time in the team

"PIGS" AND "CHICKENS" • Pig: Team member committed to success of project • Chicken: Not a pig; interested but not committed A pig and a chicken are walking down a road. The chicken looks at the pig and says, "Hey, why don't we open a restaurant? " The pig looks back at the chicken and says, "Good idea, what do you want to call it? " The chicken thinks about it and says, "Why don't we call it 'Ham and Eggs'? " "I don't think so, " says the pig, "I'd be committed but you'd only be involved. "

SCRUM FRAME WORK - EVENT S

The Sprint: period during which specific work is completed and made ready for review. Sprints are usually 2 -4 weeks long but can be as short as one week. Sprint Planning Sprint: determine which product backlog items will be delivered and how the work will be achieved. SCRUM EVENTS (CEREMONIES) The Daily Stand-up: a short communication meeting (no more than 15 minutes) in which each team member quickly covers progress since the last stand-up, planned work before the next meeting, and any impediments that may be blocking his or her progress. The Sprint Review: the "show-and-tell" or demonstration event for the team to present the work completed during the sprint. The Product Owner checks the work against pre-defined acceptance criteria and either accepts or rejects the work. The stakeholders or clients give feedback to ensure that the delivered increment met the business need. The Retrospective, or Retro, is the final team meeting in the Sprint to determine what went well, what didn't go well, and how the team can improve in the next Sprint. Retrospective is an important opportunity for the team to focus on its overall performance and identify strategies for continuous improvement on its processes.

SCRU M FRAME WORK

SPRINT PLANNING MEETING

DAILY SCRUM MEETING • Daily, ~15 minutes, Stand-up • Anyone late pays a $1 fee • Not for problem solving • Helps avoid other unnecessary meetings • Three questions answered by each team member: • What did you do yesterday? • What will you do today? • What obstacles are in your way?

SPRINT REVIEW • Team presents what it accomplished during the sprint • Attendees include the Scrum Team and key stakeholders invited by the Product Owner; • The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”; • The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved; • The Development Team demonstrates the work that it has “Done” and answers questions about the Increment; • Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next; • Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality and capability of the product.

SPRINT RETROSPECTIV E • During the Sprint Retrospective, the team discusses: • What went well in the Sprint • What could be improved • What will we commit to improve in the next Sprint

SCRUM FRAME WORK - ARTIFAC TS

PRODUCT BACKLOG • The requirements • A list of all desired work on project • Ideally expressed as a list of user stories along with "story points", such that each item has value to users or customers of the product • Prioritized by the product owner • Reprioritized at start of each sprint

USER STORIES • Instead of Use Cases, Agile project owners do "user stories" • Who (user role) – Is this a customer, employee, admin, etc. ? • What (goal) – What functionality must be achieved/developed? • Why (reason) – Why does user want to accomplish this goal? As a [user role], I want to [goal], so I can [reason]. • Example: • "As a user, I want to log in, so I can access subscriber content. " • story points: Rating of effort needed to implement this story • common scales: 1 -10, shirt sizes (XS, S, M, L, XL), etc.

USER STORIES

SAMPLE PRODUCT BACKLOG Backlog item Allow a guest to make a reservation Estimate 3 (story points) As a guest, I want to cancel a reservation. 5 As a guest, I want to change the dates of a reservation. 3 As a hotel employee, I can run Rev. PAR reports (revenue-per-available-room) 8 Improve exception handling 8 . . . 30 . . . 50

SPRINT BACKLOG • List of tasks identified by the Scrum team to be completed during the Scrum sprint. • During the sprint planning meeting, the team selects some number of product backlog items, usually in the form of user stories, and identifies the tasks necessary to complete each user story.

SPRINT BURNDOWN CHART • A display of what work has been completed and what is left to complete • one for each developer or work item • updated every day • make best guess about hours/points completed each day • Release burndown chart • shows overall progress • updated at end of each sprint

MODIFIED METHODOLOGIES § § MSF for Agile Open Unified Process

MS F F OR A GILE SOFT WA RE DEVE LOPMEN T V 5. 0 • Scrum based • In Visual Studio Application Lifecycle Management (ALM) • How to start? - > MSDN: http: //msdn. microsoft. co m/enus/library/dd 380647. aspx

AN EXAMPLE OF PRODUCT BACKLOG

AN E XAMPLE OF PRODUCT BACKLOG

OPEN UNIFIED PROCESS • The Open Unified Process (Open. UP) is a part of the Eclipse Process Framework (EPF), an open sourceprocess framework developed within the Eclipse Foundation. • Its goals are to make it easy to adopt the core of the Rational Unified Process (RUP) / Unified Process.