Informatics 43 – May 10, 2016.

Slides:



Advertisements
Similar presentations
Effort metrics: Man-month. Mythical Man Month – the book Brooks lead development of OS/360 and reflected on the problems experienced in the project. The.
Advertisements

Robert Lockyer.
Project Management Information Systems and Management.
Project Management Information Systems and Management.
Signals and Systems March 25, Summary thus far: software engineering Focused on abstraction and modularity in software engineering. Topics: procedures,
Structured Design. 2 Design Quality – Simplicity “There are two ways of constructing a software design: One is to make it so simple that there are obviously.
10 Software Engineering Foundations of Computer Science ã Cengage Learning.
The Mythical Man-Month By: Zac Lippard CS 470. What is the “Man-Month”? This is the idea that men and months are interchangeable between each other. This.
Informatics 43 – April 21, Things to know Midterm on Thursday – Closed book, closed notes, bring pen/pencil – Questions available on web site (updated)
Informatics 43 – May 7, Restatement of Goals for Testing Want to verify software’s correctness  Need to test  Need to decide on test cases  No.
Informatics 43 – May 12, Restatement of Goals for Testing Want to verify software’s correctness  Need to test  Need to decide on test cases 
Informatics 43 – May 5, Restatement of goals Want to verify software’s correctness  Need to test  Need to decide on test cases  No set of test.
Informatics 43 – April 30, What is a test case? An input to a system, and the correct output. An “input” may be complex. Example: – What is an input.
Concepts of Systems Theory
Design The goal is to design a modular solution, using the techniques of: Decomposition Abstraction Encapsulation In Object Oriented Programming this is.
SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Software design - core concepts - slide 1 Software engineering for real-time systems Section.
Computer Engineering 203 R Smith Agile Development 1/ Agile Methods What are Agile Methods? – Extreme Programming is the best known example – SCRUM.
Fall 2007CS 2251 Software Engineering Intro. Fall 2007CS 2252 Topics Software challenge Life-cycle models Design Issues Documentation Abstraction.
© 2006 Pearson Addison-Wesley. All rights reserved2-1 Chapter 2 Principles of Programming & Software Engineering.
Supplement 02 (a)Systems Theory1 Supplement 02 (a) Systems Theory And Franchise Colleges By MANSHA NAWAZ.
Cost Estimation Van Vliet, chapter 7 Glenn D. Blank.
CPIS 357 Software Quality & Testing
Why is software engineering worth studying?  Demand for software is growing dramatically  Software costs are growing per system  Many projects have.
1 CMPT 275 High Level Design Phase Architecture. Janice Regan, Objectives of Design  The design phase takes the results of the requirements analysis.
Understand Application Lifecycle Management
Project Management Work Breakdown Structures Minder Chen, Ph.D. CSU Channel Islands
Testing Basics of Testing Presented by: Vijay.C.G – Glister Tech.
Design engineering Vilnius The goal of design engineering is to produce a model that exhibits: firmness – a program should not have bugs that inhibit.
Managing Resources Program Evaluation and Review Technique (PERT) Production Process.
Mythical Man Month By Ryan Ruzich.  More software projects have gone awry for lack calendar time than all other reasons combined.
ANU comp2110 Software Design lecture 10 COMP2110 Software Design in 2004 lecture 10 Software Architecture 2 of 2 design lecture 5 of 6 Goal of this small.
Informatics 43 – May 3, Restatement of goals Want to verify software’s correctness  Need to test  Need to decide on test cases  No set of test.
Informatics 43 – May 5, Restatement of Goals for Testing Want to verify software’s correctness  Need to test  Need to decide on test cases  No.
Estimation Questions How do you estimate? What are you going to estimate? Where do you start?
MENG 446 : Management of Engineering Projects
Prepared by: Fatih Kızkun
Advanced Computer Systems
Unit - 3 OBJECT ORIENTED DESIGN PROCESS AND AXIOMS
GRASP – Designing Objects with Responsibilities
7. Modular and structured design
Why is software engineering worth studying?
Algorithms and Problem Solving
Coupling and Cohesion Rajni Bhalla.
Cyclomatic complexity
1. Welcome to Software Construction
Software engineering – 1
JOB DESIGN & JOB ANALYSIS
John D. McGregor Session 9 Testing Vocabulary
THE MYTHICAL MAN-MONTH
The Object Oriented Approach to Design
Informatics 43 – May 3, 2016.
Chapter 1 The Systems Development Environment
UNIT-4 BLACKBOX AND WHITEBOX TESTING
John D. McGregor Session 9 Testing Vocabulary
Designing and Debugging Batch and Interactive COBOL Programs
Informatics 43 – April 19, 2016.
Informatics 43 Discussion 13 May, 2016
A Few Review Questions.
On the Criteria To Be Used in Decomposing Systems into Modules D. L
Chapter 1 Introduction(1.1)
CSE403 Software Engineering Autumn 2000 Design (Overview)
Informatics 43 – April 28, 2016.
Chapter 10 – Software Testing
Cost Estimation Van Vliet, chapter 7 Glenn D. Blank.
Algorithms and Problem Solving
John D. McGregor Module 6 Session 1 More Design
Rational Rose 2000 Instructor Notes Use Case Realization Structure
Planning and Estimation
UNIT-4 BLACKBOX AND WHITEBOX TESTING
Software Testing.
Presentation transcript:

Informatics 43 – May 10, 2016

Unity workshop Unity is a popular game engine Hack is a fun and intense experience Hack is excited to present: Event: Week #8 Unity Workshop When: Wednesday, May 18 6pm-10pm Where: DBH 6011 RSVP: http://www.tinyurl.com/UnityWSHack   Description: Hello Hackers! Have you ever wanted to build your own game in VR? Do you want to see C# in action? Then come to Unity Workshop where Unity will be providing us with VR tech for you to mess around with! SCHEDULE: 6-7 PM -- Overview Unity 5.4, Adam & VR 7-10 PM -- Hands on Creating - Multiplayer Games RVSP now to guarantee yourself food at the event!  THINGS THAT YOU SHOULD BRING: A laptop with Unity downloaded (https://unity3d.com/get-unity/download)  Sponsored and hosted by: Unity

Restatement of Goals for Testing Want to verify software’s correctness  Need to test  Need to decide on test cases  No set of test cases is sufficient What is a systematic approach to the selection of test cases that will lead to accurate, thorough, repeatable identification of bugs?

The Testing Process Model Decide what to test. Select a test case input. Determine the expected output E. Run the system with the test case input. Capture the actual output A. Compare E and A. Different? Inform programmer. Loop back to 1 or 2, if time permits.

Back to Black box test case selection Equivalence Class Partitioning – a systematic approach. Identify the set of all possible inputs (to what is being tested). Identify a basis for subdividing the set of inputs. specifications, size, order, structure, your smarts think twice about defining a basis in terms of the system output Use this basis for dividing the set of all possible inputs into subsets (domain into subdomains). From each subset/subdomain, select a representative instance to be a test case input.

Equivalence Class Partitioning and the soda machine Identify the set of all possible inputs. Identify a basis for subdividing the set of inputs. Use this basis for dividing the set of all possible inputs into subsets (domain into subdomains). From each subset/subdomain, select a representative.

Another example for testing… A software function called “Password Strength”. PasswordStrength evaluates a potential password on a scale of 1 to 10. A strong password (evaluating to a higher number) has a combination of digits, symbols, and upper and lower case letters, and also is very different than the same user’s last three passwords. A weak password is shorter, similar to the last three passwords, and has less variety of characters.

Equivalence Class Partitioning and PasswordStrength Identify the set of all possible inputs. Identify a basis for subdividing the set of inputs. Use this basis for dividing the set of all possible inputs into subsets (domain into subdomains). From each subset/subdomain, select a representative.

The Mythical Man-Month Causes for scheduling disasters: We expect that all will go well. We confuse effort with progress, and think that people and months are interchangeable. Managers are often insufficiently stubborn. Schedule progress is poorly monitored. When schedule slippage is recognized, more people are added. Brooks’s Law: Adding manpower to a late software project makes it later.

Unpartitionable task “the application of more effort has no effect on the schedule”

Perfectly partitionable task “true of reaping wheat or picking cotton”

People * months = a constant Perfectly partitionable task “true of reaping wheat or picking cotton” People * months = a constant

Partitionable task requiring communication “The effort of communication must be added to the amount of work to be done.”

Task with complex interrelationships “The effort increases as n(n-1)/2. The added effort of communication may fully counteract the [benefits of the] division of the original task [among multiple workers].”

“No parts of the schedule are so thoroughly affected by sequential constraints as component debugging and system test.” What is component debugging? What is system test? Why are they affected by sequential constraints?

Your job: Go back to the “Regenerative Schedule Disaster” section of The Mythical Man-Month, and read it through carefully, making sure you understand figures 2.5 through 2.8. This exercise will pay off in your career.

Modularization A fundamental aspect of software design is dividing the whole into modules. Ideally, everything within a module interacts strongly: “High cohesion” Ideally, separate modules interact as little as possible: “Low coupling” Good decomposition into modules serves many purposes. Easier to understand each module by itself. Easier to see and understand the big picture.

Modularization A fundamental aspect of software design is dividing the whole into modules. Ideally, everything within a module interacts strongly: “High cohesion” Ideally, separate modules interact as little as possible: “Low coupling” Good decomposition into modules serves many purposes. Easier to understand each module by itself. The module coheres and is (relatively) independent. Easier to see and understand the big picture.

Modularization A fundamental aspect of software design is dividing the whole into modules. Ideally, everything within a module interacts strongly: “High cohesion” Ideally, separate modules interact as little as possible: “Low coupling” Good decomposition into modules serves many purposes. Easier to understand each module by itself. The module coheres and is (relatively) independent. Easier to see and understand the big picture. The “insides” of each module can be ignored.

Modularization Examples A photo library. Throwing a party. Air traffic control system.

UML Class Diagram