Software Engineering Modern Approaches

Similar documents
Sistemi ICT per il Business Networking

Development Process Bennett, McRobb and Farmer 1

Object-Oriented and Classical Software Engineering

Chapter 3 Software Process Model

The Top Thrill Dragster

Introduction to Software Engineering

Objectives. The software process. Topics covered. Waterfall model. Generic software process models. Software Processes

Software Processes. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1

Object-Oriented and Classical Software Engineering THE SOFTWARE PROCESS 9/17/2017. CHAPTER 3 Slide 3.2. Stephen R. Schach. Overview Slide 3.

Processes and Life- Cycles. Kristian Sandahl

Software Development Methodologies. CSC 440: Software Engineering Slide #1

Software Processes. Objectives. Topics covered. The software process. Waterfall model. Generic software process models

Topics covered. Software process models Process iteration Process activities The Rational Unified Process Computer-aided software engineering

Introduction to Software Life Cycles. CSCI 5828: Foundations of Software Engineering Lecture 06 09/08/2016

SUSE Unified Delivery Process

The Basic Waterfall Model. Software Process Models. Concurrent Development. (Concurrent Development) The Agile Critique of the Waterfall

CMPT 275 Software Engineering

A New Divide & Conquer Software Process Model

Introduction to Software Life Cycles and Agile. CSCI 5828: Foundations of Software Engineering Lecture 03 09/02/2014

Software Development Life Cycle:

Volume 8, No. 1, Jan-Feb 2017 International Journal of Advanced Research in Computer Science RESEARCH PAPER Available Online at

Pertemuan 2. Software Engineering: The Process

Introduction to Agile/Extreme Programming

An Oracle White Paper February Oracle Unified Method (OUM) Oracle s Full Lifecycle Method for Deploying Oracle-Based Business Solutions

Command and Control Software Development Lessons Learned. Lt Col Michael D. Sarchet Deputy Director, Space Systems Command and Control Division

The software process

SDLC Models- A Survey

Lectures 2 & 3. Software Processes. Software Engineering, COMP201 Slide 1

Agile Development Doesn t Have to Mean Fragile Enterprise Processes

Software Modeling & Analysis. - Fundamentals of Software Engineering - Software Process Model. Lecturer: JUNBEOM YOO

Software Life Cycle. Main Topics. Introduction

Criteria for Method Selection and Process Design of a Technical Development Strategy

DRAFT. Effort = A * Size B * EM. (1) Effort in person-months A - calibrated constant B - scale factor EM - effort multiplier from cost factors

Requirements Analysis and Design Definition. Chapter Study Group Learning Materials

Session 11E Adopting Agile Ground Software Development. Supannika Mobasser The Aerospace Corporation

The Unified Software Development Process

Software Engineering Lecture 5 Agile Software Development

BCS THE CHARTERED INSTITUTE FOR IT. BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 6 Professional Graduate Diploma in IT SOFTWARE ENGINEERING 2

Introduction to Software Project Management. CITS3220 Software Requirements & Project Management

This tutorial also elaborates on other related methodologies like Agile, RAD and Prototyping.

03. Perspective Process Models

Rational Unified Process

Model Driven Development Needs More Than Product Models

V Model material adapted from Steve Easterbrook. Waterfall Model material adapted from Steve Easterbrook. Lifecycle of Software Projects

Major attributes of the Lifecycle. The Systems Development Lifecycle. Project phases. Planning. Design. Analysis

AGILE DEVELOPMENT AND ITS IMPACT ON PRODUCTIVITY

Inception. Describe the vision and business case for this project. Determine if the enterprise should build or buy the necessary system.

Note 10: Software Process

Introduction to Systems Analysis and Design

SDLC Submitted in partial fulfillment of the requirement for the award of Degree of Computer Science

Software development activities

Requirements Engineering and Agile Methodology

Project Plan. CxOne Guide

What are requirements? Basics of Requirement Engineering. Definition of a Stakeholder. Stated Vs. Real Requirements. Stated Vs.

Passit4Sure.OG Questions. TOGAF 9 Combined Part 1 and Part 2

Based on Software Engineering, by Ian Sommerville Coherent sets of activities for specifying, designing, implementing and testing software systems

Requirements for an MDM Solution

Selecting Software Development Life Cycles. Adapted from Chapter 4, Futrell

Continuous Quality Assurance

The Agile PMP Teaching an Old Dog New Tricks

CMMI-DEV V1.3 CMMI for Development Version 1.3 Quick Reference Guide

The Product Creation Process

PMBOK Guide Fifth Edition Pre Release Version October 10, 2012

Software Reviews Since Acquisition Reform Architecture-Driven Considerations

The Product Manager and the Product Development Process. Martin Cagan Silicon Valley Product Group

Can Your Proposal Process Be More Agile?

Sample Exam ISTQB Agile Foundation Questions. Exam Prepared By

Information Systems Development

MSO Lecture 2. Wouter Swierstra (adapted by HP) September 14, 2017

Data Collection for Agile Projects Blaze Smallwood ICEAA Conference 2016

Learning Objectives. Agile Modeling and. Major Topics. Prototyping. Patched Up Prototype. Agile Modeling, but First. Prototyping

Rekayasa Perangkat Lunak 2 (IN043): Pertemuan 10. * Construction, Installation and Operations * Agile Method Software Development

SWE 211 Software Processes

An Evolutionary Lifecycle Model with Agile Practices for Software Development at ABB

The Macro Process Is the Micro Process

Agile Surveillance Points

Chapter 8. Systems Development. Ralph M. Stair George W. Reynolds

[Name] [ ID] [Contact Number]

Copyright Software Engineering Competence Center

Agile Architecture And Design

Chapter 1 Systems Development in an Organization Context

Chapter 3 Agile Software Development

18-642: Software Development Processes

Project Plan Version 1.0

Waterfall model is the earliest SDLC approach that was used for software development.

Project Management Context Outline

software development lifecycle (sdlc) models & agile methods

Software Engineering II - Exercise

CMMI-SVC V1.3 CMMI for Services Version 1.3 Quick Reference Guide

AGILE methodology- Scrum

Requirements Analysis

Scrum, Creating Great Products & Critical Systems

SOA Research Agenda. Grace A. Lewis

Agile Quality Management

Agile, IT, and the Business Community

Case Study: How to Eliminate Flaws of Waterfall and Agile Development Processes Using a Hybrid Model

SE420 Software Quality Assurance

Best Practices for Enterprise Agile Transformation

Collaborative Development of Systems Architecting Design Rules

Harnessing the power of agile development

Transcription:

Software Engineering Modern Approaches Chapter : Software Process Eric Braude and Michael Bernstein Maintenance Testing The Software Development Lifecycle Implementation Design Phase most relevant to this chapter is shown in bold Planning Requirements analysis Learning goals of this chapter What are the main activities of software processes? What are the main software process types? How would a team such a student team go about selecting a process? Software Process Software project composed of activities E.g. planning, design, testing, etc. Activities organized into phases A software process: prescribes the order and frequency of phases specifies criteria for moving from one phase to the next defines the deliverables of the project 4 Umbrella Activities Software Process Benefits Generic activities implemented throughout the life of a project Project management Configuration management Quality management Risk management 5 Process DOES NOT mean overhead unnecessary paperwork longer schedules etc. Software process has positive effect if applied correctly Meet schedules Higher quality More maintainable 6

Software Process Phases Example Video Store Application Phases of Software Processes Software Process Phases: Video Store Example. Inception Software product is conceived and defined. Planning Inception An application is needed to keep track of video rentals Planning (Software Project Management Plan) The project will take months, require 0 people and cost $M Initial schedule, resources and cost are determined Requirements Analysis (Product: Software Requirements Spec.). Requirements Analysis Specify what the application must do; answers what? The clerk shall enter video title, renter name and date rented. The system shall Design (Software Design Document: Diagrams and text) classes DVD, VideoStore,, related by 4. Design Implementation (Source and object code) Specify the parts and how they fit; answers how? 5. Implementation Write the code class DVD{ String title; } Testing (Software Test Documentation: test cases and test results) Ran test case: Rent The Matrix on Oct ; rent SeaBiscuit on Oct 4; return The Matrix on Oct 0 6. Testing Execute the application with input test data 7. Maintenance Result: SeaBiscuit due Oct 4, 004 balance of $8. (correct) Maintenance (Modified requirements, design, code, and text) Defect repair: Application crashes when balance is $0 and attempt is made to rent Gone With the Wind. Repair defects and add capability Enhancement: Allow searching by director. 7 8 Waterfall Process Waterfall Process with feedback The Waterfall Software Process The Waterfall Software Process with Feedback time time Requirements Requirements Design Design Phases (activities) Implementation Phases (activities) Implementation Testing Testing Maintenance Maintenance 9 0 Waterfall Process Advantages Waterfall Process Disadvantages Simple and easy to use Practiced for many years Easy to manage Facilitates allocation of resources Works well for smaller projects where requirements are very well understood Requirements must be known up front Hard to estimate reliably No feedback of system by stakeholders until after testing phase Major problems aren t discovered until late in process Lack of parallelism Inefficient use of resources

Iterative and Incremental Iterative repeated execution of the waterfall phases, in whole or in part, resulting in a refinement of the requirements, design and implementation Incremental operational code produced d at the end of an iterationti supports a subset of the final product functionality and features Iterative and Incremental (cont.) Requirements analysis Iterative and Incremental Development M I L E S T O N E S First iteration completed X Product released X S C H E D U L E Iteration # Design time Artifacts evolve during each phase Coding Artifacts considered complete only when software is released Testing Software Subset Software Subset Final Version 4 Release Types Prototyping Proof of concept Prototype Rationale Feasibility study Prototype Internal release External release Prototype timeline Prototype implements risky parts of this activity first Project beginning Key: n 4 5 Main project timeline = end of a unit of time = Activity with risk time 5 6 Prototyping (cont.) Prototyping (cont.) Calculate payoff in detail Prototype Payoff: First Cut Perceived value of prototype low highh Payoff from building prototype Payoff from ($ s building saved prototype per $ spent) ($ s saved per $ spent) Prototype Prototype Payoff Payoff optimal full optimal full expenditure project expenditure project on expenditure on expenditure prototype prototype Low prototype cost maybe High prototype cost no yes maybe Calculate payoff in detail 0% % expenditure 0% on % prototype expenditure 00% 00% on prototype GUI GUI only waste of resources only waste of resources 7 8

Prototyping (cont.) Spiral Model Prototype Payoff Calculations for E-commerce Clothing Application Esti- Gross Benefit Percentage Net Payoff mated excluding of prototype cost code re-use code reused in min max application min max average Prototype feature B D E C D-(-C)B D(C)B E-(-C)B E(C)B. GUI screenshots $0,000 $0,000 $80,000 50% $5,000 $75,000 $40,000. Transaction $50,000 $0,000 $00,000 80% $0 $90,000 $45,000 security. Complete $80,000 $0,000 $400,000 50% -$0,000 $00,000 $85,000 transaction 4. Customer $0,000 $0,000 $40,000 0% -$64,000 $56,000 -$4,000 tries on clothing Barry Boehm, TRW Defense Systems,988 One of the earliest and best known iterative and incremental processes Risk-driven process Project starts at the center, and each cycle of the spiral represents one iteration Goal of each cycle is to increase the degree of system definition and implementation, while decreasing the degree of risk 9 0 Spiral Model Spiral Model Iteration Steps The Spiral Model. Identify critical objectives and constraints. Evaluate project and process alternatives. Identify risks 4. Resolve (cost-effectively) a subset of risks using analysis, emulation, benchmarks, models and prototypes START 5. Develop project deliverables including requirements, design, implementation and test 6. Plan for next and future cycles update project plan including schedule, cost and number of remaining iterations 7. Stakeholder review of iteration deliverables and their commitment to proceed based on their objective being met Spiral Model Advantages Spiral Model Disadvantages Risks are managed early and throughout the process risks are reduced before they become problematic Complicated to use - risk analysis requires highly specific expertise. There is inevitably some overlap between iterations. Software evolves as the project progresses - errors and unattractive alternatives eliminated early. Planning is built into the process each cycle includes a planning step to help monitor and keep a project on track. May be overkill for small projects complication may not be necessary for smaller projects. Does not make sense if the cost of risk analysis is a major part of the overall project cost. 4 4

Unified Process Developed by Jacobson, Rumbaugh and Booch Major elaboration and refinement of Spiral Use-case driven Commercial product: Rational Unified Process (RUP) Unified Process Unified Process http://www.ambysoft.com/downloads/managersintrotorup.pdf 5 6 Inception Elaboration Establish feasibility Make business case Establish product vision and scope Estimate cost and schedule, including major milestones Assess critical risks Build one or more prototypes Specify requirements in greater detail Architectural baseline Iterative implementation of core architecture Refine risk assessment and resolve highest risk items Define metrics Refine project plan, including detailed plan for beginning Construction iterations 7 8 Construction Transition Complete remaining requirements Iterative implementation of remaining design Thorough testing and preparation of system for deployment Beta tests Correct defects Create user manuals Deliver the system for production Training of end users, customers and support Conduct lessons learned 9 0 5

Unified Process Milestones Unified Process Milestones Phases Times UP Phases - Typical Time Distribution Inception Elaboration Construction Transition Transition 0% Inception 0% Lifecycle Objectives (LCO) Scope concurrence Initial requirements definition Plan concurrence Risk acceptance Process acceptance Business case Project plan Lifecycle Architecture (LCA) Requirements stability Architecture stability Risk acceptance Cost acceptance Realistic chance to succeed Project plan Initial Operational Capability (IOC) System stability Requirements stability Prepared stakeholders Risk acceptance Cost acceptance Project plan Product Release (PR) Business acceptance Operations acceptance Support acceptance Cost and estimate acceptance Construction 55% Elaboration 5% Adapted from: Ambler, S.W., A Manager's Introduction to the Rational Unified Process (RUP) Adapted from http://www.ambysoft.com/downloads/managersintrotorup.pdf Agile Processes The Agile Process Agile processes value The Agile Manifesto: individuals and interactions over processes and tools working software over comprehensive documentation customer collaboration over contract negotiation Demonstrate fulfillment of previous stories Identify stories for this iteration Interact with customer Cement mutual understanding di Implement stories Work incrementally Develop test bank in parallel Accumulating functionality responding to change over following a plan Typical iteration Time; composed of equal iteration intervals 4 Open Source Open Source (cont.) Reasons for Making a Project Open Source Leveraging large number of resources Reasons for Making a Project Open Source Professional satisfaction To enable tailoring and integration Academic and research To gain extensive testing To damage a competitor's product To T gain market knowledge To support a core business To maintain more stably Richard Stallman Originator of open source development http://stallman.org/ To support services 5 6 6

Open Source (cont.) Reasons Against Open Source Maintainability Index: OSS vs. CSS Same Application Documentation inconsistent or poor No guarantee that developers will appear No management control No control over requirements Visibility to competitors Bill Gates http://www.microsoft.com/billgates/default.asp 7 Communications of the ACM v 47, Number 0 (004), Pp 8-87; Open source software development should strive for even greater code maintainability ; Ioannis Samoladas, Ioannis Stamelos, Lefteris Angelis, Apostolos Oikonomou 8 Maintainability Index: OSS vs. CSS Same Application Hybrid Open Source / Proprietary Processes Cumulative revenue Release Sales, service, productivity, Time Cumulative expense development Open source maintenance Communications of the ACM v 47, Number 0 (004), Pp 8-87; Open source software development should strive for even greater code maintainability ; Ioannis Samoladas, Ioannis Stamelos, Lefteris Angelis, Apostolos Oikonomou 9 Proprietary 40 Collabnet Enterprise Edition Initial Student Team Meeting: General Issues. Set agenda and time limits.. Choose the team leader.. Get everyone s commitment to required time Define an expected average number of hours per week Gather dates of planned absences 4. Take a realistic census of team skills Common problem: inflated programming skill claims 5. Begin forming a vision of the application 6. Decide how team will communicate. 7. Take meeting minutes with concrete action items http://www.collab.net/products/index.html 4 4 7

Communication Precepts. Listen to all with concentration Don t pre judge. Give all team members a turn See the value in every idea. Don t make assumptions Ask questions to clarify 4. When in doubt, communicate Communication Plan. Meetings: Team will meet each Monday from... to... in Caveat: do not replace face to face meeting with remote meetings unless remote meetings are clearly effective.. Meeting alternative: Team members should keep Fridays open from... to... in case an additional meeting is required.. Standards: Word processor, spreadsheet, compiler,. 4. E mail: Post e mails?; require acknowledgement? Caveat: e mail is poor for intensive collaboration 6. Collaboration: Tools for group collaboration and discussion e.g. Yahoo Groups, Wiki tool, Google tools, 7. Other tools: Microsoft Project (scheduling), Group calendar, 4 44 8