The Problems with Software Engineering Where do we go wrong? The UML lecture notes are based in part on those developed originally by Mats PE Heimdahl.

Slides:



Advertisements
Similar presentations
© PKD, Asst. Professor, CIT UPES | Sept 2013 | Engineering & Elicitation.
Advertisements

CSC340: Tutorial 1 Software Lifecycles TA: Yuan An Date: 9:00-10:00am, Fri. Oct. 3, 2003 Location: BA1130.
Chapter 3 Process Models
CHAPTER 1 SOFTWARE DEVELOPMENT. 2 Goals of software development Aspects of software quality Development life cycle models Basic concepts of algorithm.
MIS 325 PSCJ. CASE STUDY Using UML diagrams model business processes for a medium-sized enterprise whose main business is the development and support.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 6/e (McGraw-Hill 2005). Slides copyright 2005 by Roger Pressman.1.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
1 R&D SDM 1 Software Project Management Requirements Analysis 2010 Theo Schouten.
Ch 4 The Process page 1CS 368 Building Software is Difficult often delivered late often over budget always with errors must be a custom solution complexity.
Systems Development Life Cycles. The Traditional Systems Development Life Cycle.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
Software Engineering CSE470: Requirements Analysis 1 Requirements Analysis Defining the WHAT.
Requirements Analysis 2. 1 Req. Capture b502.ppt © Copyright De Montfort University 2000 All Rights Reserved INFO2005 Requirements Analysis Requirements.
IS550: Software requirements engineering Dr. Azeddine Chikh 4. Validation and management.
1 SWE Introduction to Software Engineering Lecture 11 - Requirements Engineering Processes.
Software Engineering CSE470: Cheng and McUmber Software Engineering CSE470 (Fall 2001) Instructors: Dr. B. Cheng (Sect. 1-3) Dr. W. McUmber (Sect. 4-6)
Requirements Engineering Process – 1
Unified Software Development Process (UP) Also known as software engineering process SEP describes how requirements are turned into software Defines who,
Profile and a quick introduction Software Engineering: ) هندسة البرمجيات (in Arabic: is the branch of computer science Designed to develop a set rules.
IT Systems Analysis & Design
Chapter 4 – Requirements Engineering
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Requirements Engineering Processes l Processes used to discover, analyse and.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Requirements Engineering Processes l Processes used to discover, analyze and.
Higher Computing Software Development. Software Development Process There are 7 main stages involved in developing a new software program: Analysis Design.
 To describe the principal requirements engineering activities and their relationships  To introduce techniques for requirements elicitation and analysis.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
CS451 - Lecture 3 1 CS451 Lecture 3: Software Lifecycle and Product Yugi Lee STB #555 (816) * Acknowledgement:
Systems Design Approaches The Waterfall vs. Iterative Methodologies.
Software Engineering Saeed Akhtar The University of Lahore Lecture 7 Originally shared for: mashhoood.webs.com.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 4: Developing Requirements.
Approaching a Problem Where do we start? How do we proceed?
1 SWE Introduction to Software Engineering Lecture 4.
ECE450 - Software Engineering II1. 2 ECE450 – Software Engineering II Today: Introduction to Requirements Engineering adapted from Steve Easterbrook’s.
Lecture Introduction to Software Development SW Engg. Development Process Instructor :Muhammad Janas khan Thursday, September.
Requirements & Specification (Chapter 10) CPSC 356 Database Ellen Walker Hiram College (Includes figures from Database Systems by Connolly & Begg, © Addison.
Learning Target: Rights and Responsibilities of citizenship.
Software Engineering, 8th edition. Chapter 7 1 Courtesy: ©Ian Sommerville 2006 March 20 th, 2008 Lecture # 12 Requirements Engineering Processes.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
Chapter 13: Software Life Cycle Models Omar Meqdadi SE 273 Lecture 13 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
Bell Work2/5/14 Solve the system by graphing. Yesterday’s Homework 1.Any questions? 2.Please pass your homework to the front. Make sure the correct heading.
Requirements / Specifications. 01/18/10CS-499G2 Requirements Determine what the customer needs (wants) the software to do  What are requirements?  An.
Requirements Engineering Requirements Elicitation Overview of Requirements Analysis.
Software Design. A well-known phenomenon You will learn…. –Thinking "object oriented“ –Define requirements and analyze the problem domain. –Design of.
Software Development Life Cycle (SDLC)
Lecture 4: Requirements Engineering COSI 120b, Principles of Software Engineering.
 Many models have been proposed to deal with the problems of defining activities and associating them with each other  The first model proposed was the.
1 The Requirements Problem Chapter 1. 2 Standish Group Research Research paper at:  php (1994)
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
Requirement Engineering
Requirement engineering & Requirement tasks/Management. 1Prepared By:Jay A.Dave.
4+1 View Model of Software Architecture
Requirement Analysis SOFTWARE ENGINEERING. What are Requirements? Expression of desired behavior Deals with objects or entities, the states they can be.
Software Engineering Saeed Akhtar The University of Lahore Lecture 3 Originally shared for: mashhoood.webs.com.
CSCI 383 Object-Oriented Programming & Design Lecture 7 Martin van Bommel.
Welcome to Software Project Management. CONVENTIONAL SOFTWARE MANAGEMENT The BEST and WORST thing about software is its flexibility. 1.Software development.
Solving Systems by Substitution (isolated) 3/16/2016 Objective: solve a linear system by substitution when a term is already isolated. Students will solve.
Dillon: CSE470: ANALYSIS1 Requirements l Specify functionality »model objects and resources »model behavior l Specify data interfaces »type, quantity,
1 Requirements Analysis Lecture # Recap of Requirements Elicitation - 1 Requirements elicitation deals with discovering requirements for a software.
 The processes used for RE vary widely depending on the application domain, the people involved and the organisation developing the requirements.  However,
Lecturer: Eng. Mohamed Adam Isak PH.D Researcher in CS M.Sc. and B.Sc. of Information Technology Engineering, Lecturer in University of Somalia and Mogadishu.
Additional slides to accompany Chapter 3 : Process Model.
OSLC PLM Workgroup1 Towards detailed use cases and alignment to OSLC V0.1 Gray Bachelor 18 th July 2011.
Elaboration & Negotiation Process
Human Errors and the Error Abstraction Process
Software Development Approaches
Requirements Engineering Process – 1
Software Requirement and Specification
Requirements Engineering Lecture 6
Software Requirements
Software Requirements
Presentation transcript:

The Problems with Software Engineering Where do we go wrong? The UML lecture notes are based in part on those developed originally by Mats PE Heimdahl

Common Problems The requirements are wrong Incomplete, inconsistent, or ambiguous The developer and the customer did not interpret the requirements the same way Requirements drift The requirements tend to change throughout the project Late design changes Continual change The functionality of the system continually changes Many changes come late in the project Many changes during maintenance Breakdown of system structure The system finally becomes unusable

Solutions Rigorous requirements and planning stage Make sure all stakeholders understand and agree on the requirements Structure the system design to accommodate change Isolate parts that are likely to change Modularize so changes are contained Attempt to not compromise system structure during change

Use-Cases and Scenarios A powerful approach to find out what the requirements on the system are Helps the analysts identify The various users of the system  Humans, software, and machines The functions the system must provide Provide more stable requirements