CompSci 230 Software Construction

Slides:



Advertisements
Similar presentations
Testing and Quality Assurance
Advertisements

Ch 3: Unified Process CSCI 4320: Software Engineering.
Chapter 2 – Software Processes
Software Modeling SWE5441 Lecture 3 Eng. Mohammed Timraz
Chapter 11: Testing The dynamic verification of the behavior of a program on a finite set of test cases, suitable selected from the usually infinite execution.
Functional Testing Test cases derived from requirements specification document – Black box testing – Independent testers – Test both valid and invalid.
Categories of Testing.
1 Software Testing (Part-II) Lecture Software Testing Software Testing is the process of finding the bugs in a software. It helps in Verifying and.
CompSci 230 Software Design and Construction
Software Systems Verification and Validation Laboratory Assignment 3 Integration, System, Regression, Acceptance Testing Assignment date: Lab 3 Delivery.
Software testing basic. Main contents  Why is testing necessary?  What is testing?  Test Design techniques  Test level  Test type  How to write.
Software Testing Testing principles. Testing Testing involves operation of a system or application under controlled conditions & evaluating the results.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
What is a Business Analyst? A Business Analyst is someone who works as a liaison among stakeholders in order to elicit, analyze, communicate and validate.
Testing Workflow In the Unified Process and Agile/Scrum processes.
SOFTWARE ENGINEERING MCS-2 LECTURE # 3. SOFTWARE PROCESS  A software development process, also known as a software development life- cycle (SDLC), is.
University of Palestine software engineering department Testing of Software Systems Testing throughout the software life cycle instructor: Tasneem.
Software Construction Lecture 18 Software Testing.
CS 5150 Software Engineering Lecture 3 Software Processes 2.
TESTING LEVELS Unit Testing Integration Testing System Testing Acceptance Testing.
Chapter 2 – Software Processes Lecture 1 Chapter 2 Software Processes1.
Chapter 8 Testing. Principles of Object-Oriented Testing Å Object-oriented systems are built out of two or more interrelated objects Å Determining the.
Software Quality Assurance and Testing Fazal Rehman Shamil.
Waterfall Model Software project Management. Waterfall Model  The Waterfall Model was first Process Model to be introduced. It is also referred to as.
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.
Week # 4 Quality Assurance Software Quality Engineering 1.
Applied Software Project Management SOFTWARE TESTING Applied Software Project Management 1.
Methodologies and Algorithms
Software Testing.
SOFTWARE TESTING Date: 29-Dec-2016 By: Ram Karthick.
PREPARED BY G.VIJAYA KUMAR ASST.PROFESSOR
Lecture 3 Prescriptive Process Models
User-centred system design process
CS 389 – Software Engineering
SOFTWARE TESTING OVERVIEW
CompSci 230 Software Construction
Topic for Presentaion-2
PROJECT LIFE CYCLE AND EFFORT ESTIMATION
Software Processes (a)
Quality Management Perfectqaservices.
Prototype Model Lecture-4.
Software development life cycle models
Models of Software Development Life Cycle (SDLC)
Some Simple Definitions for Testing
Level 1 Level 1 – Initial: The software process is characterized as ad hoc and occasionally even chaotic. Few processes are defined, and success depends.
CHAPTER 2 Testing Throughout the Software Life Cycle
Software Processes.
Introduction to Software Engineering
Teaching slides Chapter 1.
Chapter 2 – Software Processes
Introduction to Software Testing
Chapter 2 Software Processes
Software Engineering Lecture 18.
Lecture 09:Software Testing
Software Development Process
Chapter 2 – Software Processes
Software life cycle models
Testing and Test-Driven Development CSC 4700 Software Engineering
CS240: Advanced Programming Concepts
Practical Software Engineering
Baisc Of Software Testing
UNIT 5 EMBEDDED SYSTEM DEVELOPMENT
UNIT 5 EMBEDDED SYSTEM DEVELOPMENT
Software Engineering Lecture 17.
CIS 4328 – Senior Project 2 And CEN Engineering of Software 2
Rapid software development
CMPE/SE 131 Software Engineering April 11 Class Meeting
Chapter 11: Integration- and System Testing
SDLC (Software Development Life Cycle)
Presentation transcript:

CompSci 230 Software Construction Lecture Slides #24: Waterfall Development S1 2016

Agenda Topics: The Waterfall model of software development Testing under waterfall Pros and cons of waterfall development CompSci 230: WF

The “waterfall” model Dates back to 1968! Models software development as a linear multi-stage manufacturing process Linear: stages follow distinctly after each other, each stage feeds into the next stage only, any iterations and feedback happen within each stage only Each stage must be completed before the start of the next stage Each stage is verified against the previous stage and then signed off No stage is complete without sign-off Think of a waterfall tumbling down over several stages Water flows downhill only First general attempt at software engineering CompSci 230: WF

Stages of the waterfall process Decision stage Develop the business case Gather user requirements Write system specification (generally an SRS) Design stage System design Component design Development stage Build the components Demonstration stage Testing Order of implementation CompSci 230: WF

Features, pros and cons of waterfall Each stage requires specific specialised skills (business analyst, system architect, developer, tester) Documentation plays a key role Stages can take a long time to implement Requirements may change during this period Resulting product may not be what is needed CompSci 230: WF

Testing in waterfall Testing mirrors the (sub)stages, in reverse order Stage / Test: Component test: (unit test) verifies against component design Performed by developer or independent tester as white or black box test Challenges: see black box / white box testing Interface test (integration test): verifies against system design Performed by developer(s) or independent tester Challenges: is understanding of interfaces correct? Tests of this type tend to throw up a lot of issues. System test: verifies against system specification Performed by dedicated tester(s) Challenges: Ideally ought to be done in a production-like environment, which is difficult to establish for testing only Acceptance test: verifies against user requirements Performed by customer or dedicated tester(s) Challenges: Ideally ought to be done in user environment, which can be difficult to establish for testing only Release test: verifies against business case Performed by customer and or specialised operations team in live environment Challenges: business risk of failures becoming apparent at this stage CompSci 230: WF

Other types of testing Portability testing Smoke testing Generally done by code inspection (at component test level) or during integration / system testing as black box tests Challenges: tends to throw up a lot of issues requiring significant additional development work Smoke testing Superficial test of system before handover for proper system test to catch obvious faults Usability testing Performed with the help of users to see how quickly users learn and operate the system Load testing: ensure system can cope with expected maximum load. Challenges: replicating behavior of a large number of users, replicating physical environment (latency & bandwidth constraints) Stress testing: load testing to determine the maximum load that the system is able to support Regression testing Used during component, interface and system test to ensure changes to a previous version don’t break functionality CompSci 230: WF

Waterfall - challenges Non-overlapping nature of stages and tests means projects tend to take a long time Needs of stakeholders change over time What gets built may not be the right thing Reliance on documentation means that a large amount of documentation needs to be managed Documents are difficult to keep up to date and consistent Documentation doesn’t capture informal knowledge of the actors in the various stages E.g., SRS contains lots of detail but may be relatively brief on “big picture” stuff because it requires domain knowledge, which developers may not have. So developers may fail to see the forest for the trees. CompSci 230: WF

Review Which are the stages of the waterfall model? Which types of testing correspond to these stages? Name a few reasons that cause projects following the waterfall model to take a long time What are the advantages and risks of the waterfall model? CompSci 230: WF