Software Requirements: Overview and Motivation Gruia-Catalin Roman and Christopher Gill CSE 436 January 2007 Department of Computer Science and Engineering.

Slides:



Advertisements
Similar presentations
A presentation from June 20, 2000 Jim Brosseau The ‘How-To’ of Software Process Improvement.
Advertisements

Software Engineering CSE470: Process 15 Software Engineering Phases Definition: What? Development: How? Maintenance: Managing change Umbrella Activities:
Chapter 7: Key Process Areas for Level 2: Repeatable - Arvind Kabir Yateesh.
More CMM Part Two : Details.
How ISO9001 Compares with CMM Mark C. Paulk JAN,1995 CMM version 1.1 ISO9001 July 1994 presented by Zhilan Zhou.
1 State of Michigan Achieving Software Process Improvement with Capability Maturity Model (CMM)
© Devon M.Simmonds, 2007 CSC 550 Graduate Course in Software Engineering ______________________ Devon M. Simmonds Computer Science Department University.
Chapter 2 The Software Process
©2006 OLC 1 Process Management: The Foundation for Achieving Organizational Excellence Process Management Implementation Worldwide.
CPIS 357 Software Quality & Testing I.Rehab Bahaaddin Ashary Faculty of Computing and Information Technology Information Systems Department Fall 2010.
Planning a measurement program What is a metrics plan? A metrics plan must describe the who, what, where, when, how, and why of metrics. It begins with.
R R R CSE870: Advanced Software Engineering (Cheng): Intro to Software Engineering1 Advanced Software Engineering Dr. Cheng Overview of Software Engineering.
June 1, 2004Computer Security: Art and Science © Matt Bishop Slide #18-1 Chapter 18: Introduction to Assurance Overview Why assurance? Trust and.
Capability Maturity Model (CMM) in SW design
Computer Engineering 203 R Smith Process/Plan Model 7/ Development Process Models Development Process Models are different ways to look at the processes.
Questions: Choice the correct answer: 1-Capability Maturity Model for Software (SW-CMM) is used to: a- increase software process capability. b- increase.
1 R&D SDM 1 Software Project Management Capability Maturity Model 2009 Theo Schouten.
CMM Overview - 1 © Paul Sorenson CMPUT Software Engineering refs. IEEE Software, March 1988, 73-79, and IEEE Software, July 1993, (Capability.
Chapter 3 The Structure of the CMM
Configuration Management
Software Process CS 414 – Software Engineering I Donald J. Bagert Rose-Hulman Institute of Technology December 17, 2002.
How ISO 9001 Fits Into The Software World? Management of Software Projects and Personnel CIS 6516 March 6, 2006 Prepared by Olgu Yilmaz Swapna Mekala.
Software Engineering Institute Capability Maturity Model (CMM)
Capability Maturity Model
SOFTWARE QUALITY ASSURANCE Asst. Prof. Dr. Selim BAYRAKLI Maltepe University Faculty of Engineering SE 410.
Chapter : Software Process
The Key Process Areas for Level 2: Repeatable Ralph Covington David Wang.
S T A M © 2000, KPA Ltd. Software Trouble Assessment Matrix Software Trouble Assessment Matrix *This presentation is extracted from SOFTWARE PROCESS QUALITY:
Chapter 4 Interpreting the CMM. Group (3) Fahmi Alkhalifi Pam Page Pardha Mugunda.
Software Engineering II Lecture 1 Fakhar Lodhi. Software Engineering - IEEE 1.The application of a systematic, disciplined, quantifiable approach to the.
Chapter © 2009 Pearson Education, Inc. Publishing as Prentice Hall.
Developing IT Capabilities
Software Project Management
Capability Maturity Model Part One - Overview. History Effort started by SEI and MITRE Corporation  assess capability of DoD contractors First.
Dillon: CSE470: SE, Process1 Software Engineering Phases l Definition: What? l Development: How? l Maintenance: Managing change l Umbrella Activities:
N By: Md Rezaul Huda Reza n
1 Chapter 2 The Process. 2 Process  What is it?  Who does it?  Why is it important?  What are the steps?  What is the work product?  How to ensure.
Demystifying the Business Analysis Body of Knowledge Central Iowa IIBA Chapter December 7, 2005.
CMM Level 2 KPA’s CS 4320 Fall Requirements Management 1 Goals: – System requirements allocated to software are controlled using a baseline for.
Introduction to Software Engineering LECTURE 2 By Umm-e-Laila 1Compiled by: Umm-e-Laila.
Chapter 2 Process: A Generic View
Lecture 1 Introduction to Software Engineering
Software Engineering Lecture # 17
Capability Maturity Model. History Effort started by SEI and MITRE Corporation  assess capability of DoD contractors First version published in.
By Ritesh Reddy Nagaram.  Organizations which are developing software processes are facing many problems regarding the need for change of already existing.
Georgia Institute of Technology CS 4320 Fall 2003.
SWEN 5130 Requirements Engineering 1 Dr Jim Helm SWEN 5130 Requirements Engineering Requirements Management Under the CMM.
 Management ◦ The activities and tasks undertaken by one or more persons for the purpose of planning and controlling the activities of other in order.
CS Process Improvement CMM Hans Van Vliet, Software Engineering, Principles and Practice, 3 rd edition, John Wiley & Sons, Chapter 6. W. Humphrey,
Ch-1 Introduction The processes used for executing a software project have major effect on quality of s/w produced and productivity achieved in project…
Level 1 Level 1 – Initial: The software process is characterized as ad hoc and occasionally even chaotic. Few processes are defined, and success depends.
Page 1 The Capability Maturity Model (CMM) distinguishes between immature and mature software organizations. Immature software organizations are typically.
Software Engineering (CSI 321) Software Process: A Generic View 1.
Pertemuan 14 Matakuliah: A0214/Audit Sistem Informasi Tahun: 2007.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
Capability Maturity Model. CS460 - Senior Design Project I (AY2004)2 Immature Organisations Software processes are often rigorously followed. Organisation.
Cmpe 589 Spring Fundamental Process and Process Management Concepts Process –the people, methods, and tools used to produce software products. –Improving.
Overview of CMMI Global Certification Consultant is aiming to designed CMMI Presentation to share knowledge about CMMI,
Advanced Software Engineering Dr. Cheng
State of Michigan Achieving Software Process Improvement with
CS4311 Spring 2011 Process Improvement Dr
Software Engineering (CSI 321)
Level 1 Level 1 – Initial: The software process is characterized as ad hoc and occasionally even chaotic. Few processes are defined, and success depends.
OO Design and Development
KEY PROCESS AREAS (KPAs)
Software Engineering Lecture 16.
Software Engineering I
Capability Maturity Model
Capability Maturity Model
Presentation transcript:

Software Requirements: Overview and Motivation Gruia-Catalin Roman and Christopher Gill CSE 436 January 2007 Department of Computer Science and Engineering

[ §1 : 2 ] Overview of Requirements Topics [1] Software Crisis (the motivation) [2] Life-Cycle Perspective (the context) [3] Software Requirements (the ideas) [4] Processes (applying the approach) [5] Products (results and artifacts) [6] Basic Methods (foundational techniques) [7] Complex Models (advanced techniques) [8] Reviews (evaluation and feedback)

[ §1 : 3 ] 1. Software Crisis (the motivation) Overview 1.1 Symptoms 1.2 Causes 1.3 Costs 1.4 Response

[ §1 : 4 ] 1.1 Symptoms Systems are being delivered late and over budget Denver Airport (losses of $1.1 million/day) FAA ($1 billion over budget, five years late) Systems under development are canceled due to emerging gaps between projected capabilities and understood needs two out of six major projects suffer this fate

[ §1 : 5 ] 1.1 Symptoms, Continued Completed systems meet the needs of the user only in part Some needs may never have been captured Capture may not have been rigorous / detailed Needs may have been out of scope for $ or time budgets Completed systems are never installed These problems are not limited to large and complex systems

[ §1 : 6 ] 1.2 Causes Complexity System requirements Weak management controls Lack of technical maturity

[ §1 : 7 ] 1.3 Costs The cost of correcting an error grows very rapidly as the project moves along its life-cycle This observation argues for early error detection and provides the motivation for technical reviews The highest cost errors are those involving the systems requirements formulation

[ §1 : 8 ] Implications Problems relating to the identification and documentation of system requirements present the highest risk for a project Investments in other areas of the software development process can be easily undercut Costs incurred by problems with the requirements … take away time and $ from design, implementation, testing, upgrades, etc.

[ §1 : 9 ] Implications, Continued Meaningful measurement and evaluation must consider the key relation between error introduction points error detection points Otherwise errors can persist, even propagate Limits effectiveness of the quality assurance Introduces weaknesses in development process

[ §1 : 10 ] 1.4 Response There is no silver bullet for the very difficult task of requirements definition and management The state of the art, however, is very much ahead of the state of the practice What you learn in this course, you can apply with impact A standardized framework can be the conduit for bridging the gap increased awareness common terminology assimilation of very basic practices

[ §1 : 11 ] Capability Maturity Model Capability Maturity Model (CMM) A framework designed to facilitate the introduction of basic sound practices across the industry CMM does not solve the technical problem CMM facilitates the adoption of sound technical and managerial practices

[ §1 : 12 ] Repeatable Level Key process areas Requirements management Software project management Software project tracking and oversight Software subcontract management Software quality assurance Software configuration management

[ §1 : 13 ] Requirements Management Goals Requirements are controlled to establish a baseline for technical and managerial use Plans, products, and activities are kept consistent with the requirements Commitment to perform The project follows a written organizational policy for managing system requirements Ability to perform Responsibility is established for analyzing and allocating the requirements Requirements are documented Resources are provided for managing the requirements Training is provided

[ §1 : 14 ] Performance Activities performed Requirements are reviewed prior to use Requirements are used as a basis for plans, products, and activities Changes to allocated requirements are reviewed

[ §1 : 15 ] Controls Measurement and analysis Measurements are made and used to determine the status of the activities for managing the requirements Verifying implementation Activities for managing requirements are reviewed with senior management Activities for managing requirements are reviewed with the project manager The software quality assurance group reviews activities and products