Software Processes. Minsoo Ryu. Hanyang University. Real-Time Computing and Communications Lab., Hanyang University

Similar documents
Chapter 2. Objectives

Solved MCQs Of CS615 effort, risks, and resources are the factors included in

SWEN 256 Software Process & Project Management

SOFTWARE PROJECT MANAGEMENT : WHITE

SWEN 256 Software Process & Project Management

Chapter 6. The Process of Tax Policymaking and Legislation

Committee on Payments and Market Infrastructures. Board of the International Organization of Securities Commissions. Technical Guidance

Test Coverage and MC/DC

Stakeholder Comment Matrix

Memo No. Issue Summary No. 1, Supplement No. 2. Issue Date October 29, Meeting Date(s) EITF November 12, 2015

The New ROI. Applications and ROIs

Welcome to Service Strategy To Support Digital Transformation

Executive summary 20 September 2010

The Software Engineering Discipline. Computer Aided Software Engineering (CASE) tools. Chapter 7: Software Engineering

2) What is algorithm?

Number portability and technology neutrality Proposals to modify the Number Portability General Condition and the National Telephone Numbering Plan

Project Title: INFRASTRUCTURE AND INTEGRATED TOOLS FOR PERSONALIZED LEARNING OF READING SKILL

Optimizing the Incremental Delivery of Software Features under Uncertainty

MULTI-ECHELON SUPPLY CHAIN VISIBILITY. CERTIFICATION OF PEOPLE AND MACHINES. SOFTWARE LIFECYCLE MANAGEMENT.

The views in this summary are not Generally Accepted Accounting Principles until a consensus is reached and it is ratified by the Board.

25556 The financial system:

Unified Modelling Language (UML)

ETSF01: Software Engineering Process Economy and Quality

September Preparing a Government Debt Management Reform Plan

NTA and the Macro Economy

""" ""!!J HI ERNST & YOUNG

B. Outlays Associated with Internally Generated Intangible Assets

Towards understanding the role of adverse selection and moral hazard in automated negotiation of service level agreements

IFRS accounting outline for POWER. Purchase

edigeocompliance Country Guide Poland

Standard Summary Project Fiche. Project PL : Improved Tax Administration

Copyright Sopheon plc. All rights reserved worldwide. Next

Introduction. The Assessment consists of: Evaluation questions that assess best practices. A rating system to rank your board s current practices.

NATIONAL BANK OF ROMANIA

Lecture 18: Chapter 27!

Session 5 Evidence-based trade policy formulation: impact assessment of trade liberalization and FTA

2019 Integrated Resource Plan (IRP) Public Input Meeting January 24, 2019

ELECTRONIC COMMERCE AND INDIRECT TAXATION

NYISO Capital Budgeting Process. Draft 01/13/03

FROM 12 TO 21: OUR WAY FORWARD

Business Combinations: Applying the Acquisition Method Board Meeting Handout. July 19, 2006

Using Earned Value Management (EVM) in Spiral Development

MANAGEMENT RISK INTEGRAL UNIT (UAIR)

October 17, Susan M. Cosper, Technical Director FASB 401 Merritt 7 PO Box 5116 Norwalk, CT Via to

UCISA TOOLKIT. Major Project Governance Assessment. version 1.0

Downloaded from UNITED STATES DEPARTMENT OF ENERGY EARNED VALUE MANAGEMENT APPLICATION GUIDE

SUMMARY OF THE RESPONSES TO THE PUBLIC CONSULTATION

Joint Venture on Managing for Development Results

INTER- AMERICAN CENTER OF TAX ADMINISTRATIONS 48ª. GENERAL ASSEMBLY

Wealthsimple Inc. 860 Richmond Street West, 3rd Floor, Toronto, Ontario, M6J 1C9

SEPA DIRECT DEBIT B2B RULEBOOK CHANGE REQUEST - CONSULTATION DOCUMENT COVER PAGE

PMP Exam Preparation Course. Madras Management Training W.L.L All Rights Reserved

AUDIT CERTIFICATE WORKING NOTES 6 TH FRAMEWORK PROGRAMME

Technical Debt: Why Should You Care?

Lecture 33 Blockchain in Financial Service III Financial Trade

INTERNATIONAL FEDERATION

S af e H ar b o r N o t ic e We have made forward-l ook i n g s t at emen t s i n t he p res en t at i on. O u r forwardl ook i n g s t at emen t s c

AUDIT CERTIFICATE GUIDANCE NOTES 6 TH FRAMEWORK PROGRAMME

Three Numbers to Measure Project Performance

CHAPTER 1 FINANCIAL ACCOUNTING AND ACCOUNTING STANDARDS. IFRS questions are available at the end of this chapter. TRUE-FALSE Conceptual

Delivering Business Value Gone are the days of the big bang approach. Chris Castleberry Sue Connelly

VALUE FOR MONEY AND FACILITIES PERFORMANCE: A SYSTEMS APPROACH

2018 Interconnection Process Enhancements. Addendum #2 to Draft Final Proposal

CESR Public Consultation (Ref.: CESR/06-648b) Use of reference data standard codes in transaction reporting.

T2S features and functionalities

DiCom Software 2017 Annual Loan Review Industry Survey Results Analysis of Results for Banks with Total Assets between $1 Billion and $5 Billion

1.1 Financial products

Memo No. Issue Summary No. 1 * Issue Date March 5, Meeting Date(s) EITF March 19, EITF Liaison

How private equity is tackling operational complexity

Revenue Recognition: Manufacturers & Distributors Supplement

Eliciting Theory about a Retirement Process

BS&P Guidelines for NYISO Budget Preparation/ Financing and for Project Monitoring. Draft 07/1423/03

Social Insurance in China

Upstream and downstream costs are often interdependent: eg. R+D and customer service.

HIGH COMMITTEE FOR CORPORATE GOVERNANCE APPLICATION GUIDE FOR THE AFEP-MEDEF CORPORATE GOVERNANCE CODE OF LISTED CORPORATIONS OF JUNE 2013

IT Governance for DG EAC

China s Measure in Real Term for Education and Health

T2-T2S CONSOLIDATION HIGH-LEVEL SUMMARY OF BUSINESS CHANGES

The By-Laws of t he HSC Brooklyn Chapt er Unit ed Universit y Professions

CONTACT(S) Peter Clark +44 (0) Jane Pike +44 (0)

Proposed Working Mechanisms for Joint UN Teams on AIDS at Country Level

Project Connect. June 22, 2011

Brief course information Strategic planning and project selection Project integration management Project scope management

Charles Sturt University

13 TH MEETING 2 MAY 2016

The 7 th International Scientific Conference DEFENSE RESOURCES MANAGEMENT IN THE 21st CENTURY Braşov, November 15 th 2012

FOURTH PROGRESS REPORT ON TARGET2

ONEPOINT E SOL UT IONS LAB TABLES SEF A 8M C ERTIF IED SETTING THE NEW STANDARD A UST IN, T X

Mechanism and Methods of Enterprise Financing System Flexibility

Annual Business Survey of Economic Impact 2005

This letter represents the views of CCR and not necessarily the views of FEI or its members individually.

EUROPEAN STANDARD OF ACTUARIAL PRACTICE 2 (ESAP 2) ACTUARIAL FUNCTION REPORT UNDER DIRECTIVE 2009/138/EC

Economic Framework for Power Quality

Managing contractual obligations

Innovazione tecnologica e del modello di business: il caso Street Scooter

Climate Action Reserve Forest Project Protocol Proposed Guidelines for Aggregation

REGULATIONS FOR THE IMPLEMENTATION OF THE LAW ON WHOLLY FOREIGN-OWNED ENTERPRISES. Adopted by Decision No. 60 of the Cabinet on October 27, 2000

Black-Box Testing Techniques I

ANNEX. to the COMMISSION DECISION

What About Payment System Integration? An Overview of Regional Experiences

Transcription:

Software Processes Minsoo Ryu Hanyang University

Topics covered 1. What is a Software Process? 2. Software Process Activities 3. Waterfall Development 4. Iterative and Incremental Development 5. Others 1. Spiral Development 2. Rapid Application Development 3. V Model 6. Software Process Standard 2 2

What is a Software Process Ivar Jacobson, Grady Booch, and James Rumbaugh A process defines who is doing what, when, and how to reach a certain goal It is widely accepted that the quality of the product depends on the quality of the process! Synonyms include software life cycle and software development process There are several models for such processes, each describing approaches to a variety of tasks or activities that take place during the process 3 3

Fundamental Assumptions Good processes lead to good software Good processes reduce risk Good processes enhance visibility 4 4

Variety of Software Processes Software products are very varied... Therefore, there is no standard process for all software engineering projects BUT successful software development projects all need to address similar issues This creates a number of process steps that must be part of all software projects 5 5

Basic Process Steps Feasibility and planning Requirements Design Implementation Verification and validation (acceptance and release) Operation, maintenance, and evolution It is essential to distinguish among these aspects and to be clear which you are doing at any given moment Do not confuse requirements and design 6 6

Feasibility and Planning A feasibility study precedes the decision to begin a project What is the scope of the proposed project? Is the project technically feasible? What are the projected benefits? What are the costs, timetable? A feasibility study leads to a decision Go or no-go 7 7

Requirements Analysis and Definition The requirements analysis and definition establish the system's services, constraints and goals by consultation with users They are then defined in a manner that is understandable by both users and development staff Requirements engineering process Requirements elicitation and analysis Requirements specification Requirements validation 8 8

Design and Implementation The process of converting the requirements specification into an executable system Design Design a software structure that realizes the specification Implementation Translate this structure into an executable program The activities of design and implementation are closely related and may be inter-leaved 9 9

Verification and Validation Verification and validation (V & V) is intended to show that a system conforms to its specification and meets the requirements of the system customer Verification Involves checking and review processes and system testing System testing involves executing the system with test cases that are derived from the specification of the real data to be processed by the system Validation The complete system is tested against the requirements by the client 10 10

Operation, Maintenance, and Evolution Operation: The system is put into practical use Maintenance: Errors and problems are identified and fixed Evolution: The system evolves over time as requirements change, to add new functions or adapt the technical environment Phase out: The system is withdrawn from service 11 11

Combining the Process Steps Feasibility and Planning Requirements Design & Implementation There are many ways to combine the processes Verification & Validation Operation, Maintenance, and Evolution 12 12

Sequence of Processes Every software project will include these basic processes, in some shape or form, but: They may be formal or informal They may be carried out in various sequences Examples: A feasibility study cannot create a proposed budget and schedule without a preliminary study of the requirements and a tentative design Detailed design or implementation usually reveals gaps in the requirements specification 13 13

The Waterfall Model The waterfall model is a sequential software development model (a process for the creation of software) in which development is seen as flowing steadily downwards (like a waterfall) through the phases of requirements analysis, design, implementation, testing (validation), integration, and maintenance The origin of the term "waterfall" is often cited to be an article published in 1970 by Winston W. Royce (1929 1995) although Royce did not use the term "waterfall" in this article Ironically, Royce was actually presenting this model as an example of a flawed, non-working model (Royce 1970) 14 14

The Waterfall Model 15 15

Discussions of the Waterfall Model Advantages: Process visibility Separation of tasks Quality control Cost control Disadvantages: Each stage in the process reveals new understanding of the previous stages, that requires the earlier stages to be revised 16 16

Discussions of the Waterfall Model Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements Therefore, this model is only appropriate when the requirements are well-understood and changes will be fairly limited during the design process Few business systems have stable requirements The waterfall model is mostly used for large systems engineering projects where a system is developed at several sites 17 17

Modified Waterfall Model 18 18

Iterative and Incremental Development 19 19

Iterative and Incremental Development increment # n C o m m u n i c a t i o n P l a n n i n g M o d e l i n g analy s is des ign C o n s t r u c t i o n c ode t es t D e p l o y m e n t d e l i v e r y f e e d b a c k increment # 2 deliv ery of nt h increment C o m m u n i c a t i o n P l a n n i n g M o d e l i n g increment # 1 analy s is des ign C o n s t r u c t i o n c ode t es t D e p l o y m e n t d e l i v e r y f e e d b a c k deliv ery of 2nd increment C o m m u n i c a t i o n P l a n n i n g M o d e l i n g analy s is des ign C o n s t r u c t i o n c ode t es t D e p l o y m e n t d e l i v e r y f e e d b a c k delivery of 1st increment project calendar t ime 20 20

Incremental and Iterative Incremental development is a scheduling and staging strategy in which the various parts of the system are developed at different times or rates, and integrated as they are completed The alternative to incremental development is to develop the entire system with a "big bang" integration Iterative development is a rework scheduling strategy in which time is set aside to revise and improve parts of the system It does not presuppose incremental development, but works very well with it 21 21

Advantages of Iterative and Incremental Development Customer value can be delivered with each increment so system functionality is available earlier Early increments act as a prototype to help elicit requirements for later increments Lower risk of overall project failure The highest priority system services tend to receive the most testing 22 22

Other Software Processes Spiral Development Rapid Application Development V Model 23 23

Spiral Development Proposed by Barry Bohem, 1988 Process is represented as a spiral rather than as a sequence of activities with backtracking. Each loop in the spiral represents a phase in the process No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required Risks are explicitly assessed and resolved throughout the process 24 24

Spiral Development 25 25

RAD (Rapid Application Development) Team # n M o d e lin g business m odeling dat a m odeling process modeling Communicat ion Team # 2 Mo d eling business m odeling dat a m odeling process m odeling Co n st ru ct io n com ponent reuse autom atic code generation testing Planning Team # 1 Mode ling business modeling dat a modeling process modeling Co nst ruct io n com ponent reuse aut om at ic code generat ion t est ing De ployme nt int egrat ion deliv ery feedback Const ruct ion component reuse aut omat ic code generat ion t est ing 6 0-9 0 days 26 26

V Model The V-model is a software development model which can be presumed to be the extension of the waterfall model The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing The V-model can be said to have developed as a result of the evolution of software testing The tests in the ascending (Validation) hand are derived directly from their design or requirements counterparts in the descending (Verification) hand The V can also stand for the terms Verification and Validation 27 27

V Model 28 28

ISO 12207 ISO 12207 is an ISO standard for software lifecycle processes It aims to be 'the' standard that defines all the tasks required for developing and maintaining software Standard ISO 12207 establishes a process of life cycle for software, including processes and activities applied during the acquisition and configuration of the services of the system Each Process has a set of outcomes associated with it. There are 23 Processes, 95 Activities, 325 Tasks and 224 Outcomes 29 29

ISO 12207 The standard has the main objective of supplying a common structure so that the buyers, suppliers, developers, maintainers, operators, managers and technicians involved with the software development use a common language The structure of the standard was intended to be conceived in a flexible, modular way so as to be adaptable to the necessities of whoever uses it The standard is based on two basic principles: modularity and responsibility Modularity means processes with minimum coupling and maximum cohesion Responsibility means to establish a responsibility for each process, facilitating the application of the standard in projects where many people can be legally involved The set of processes, activities and tasks can be adapted according to the software project These processes are classified in three types: basic, support and organizational The support and organizational processes must exist independently of the organization and the project being executed The basic processes are instantiated according to the situation 30 30