COMP2110 Software Design in 2003 ● a(nother) framework for Software Engineering ● the Software Engineering ideas and concepts in comp2110 ● Organisation of comp2110 in 2003 it's quite different from 2002

Main Phases of Software Process 1. Requirements Analysis (answers “WHAT?”) Specifying what the application must do 2. Design (answers “HOW?”) Specifying what the parts will be, and how they will fit together 3. Implementation (A.K.A. “CODING”) Writing the code 4. Testing (type of VERIFICATION) Executing the application with test data for input 5. Maintenance (REPAIR or ENHANCEMENT) Repairing defects and adding capability Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Software Process Phases: Personal Finance Example  Requirements Analysis: Text produced e.g., “ … The application shall display the balance in the user’s bank account. …”  Design: Diagrams and text e.g., “ … The design will consist of the classes CheckingAccount, SavingsAccount, …”  Implementation: Source and object code e.g., … class CheckingAccount{ double balance; … } …  Testing: Test cases and test results e.g., “… With test case: deposit $44.92 / deposit $32.00 / withdraw $ / … the balance was $ , which is correct. …”  Maintenance: Modified design, code, and text e.g., Defect repair: “Application crashes when balance is $0 and attempt is made to withdraw funds. …” e.g., Enhancement: “Allow operation with Euro currency.” Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

The Waterfall Software Process time Requirements Analysis Design Milestone(s) Phases (activities) Implementation Testing Maintenance Release product X Two phases may occur at the same time for a short period Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Why a Pure Waterfall Process is Usually Not Practical  Don’t know up front everything wanted and needed  Usually hard to visualize every detail in advance 1. We can only estimate the costs of implementing requirements (and the feasibility of the project) 1. To gain confidence in an estimate, we need to design and actually implement parts, especially the riskiest ones 2. We will probably need to modify requirements as a result  We often need to execute intermediate builds of programs 1. Stakeholders (clients, managers) need to gain confidence 2. Designers and developers need confirmation they're building what’s needed and wanted (use frequent incremental building and testing) 1. Team members not idle while other do requirements 1. Typically put people to work on several phases at once Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission. See also: in c2110 eBrick. Parnas and Clements, A Rational Design Process, How and Why to Fake It

The Spiral Process time 1 Requirements analysis Design Coding Testing 1Iteration # Product released X M I L E S T O N E S Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission. Intermediate version (prototype) X Intermediate version (2 nd prototype) X

Another view: overlapping phases of process Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

The Four “P’s” of Software Engineering People (by whom it is done) * * Symbology from Ivar Jacobson, O-O Software Engineering a Case Driven Approach Addison-Wesley 1994 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Process (the manner in which it is done) The Four “P’s” of Software Engineering People (by whom it is done) Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Project (the doing of it) The Four “P’s” of Software Engineering People (by whom it is done) Process (the manner in which it is done) Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

The Four “P’s” of Software Engineering People (by whom it is done) Process (the manner in which it is done) Project (the doing of it) Product (the application artifacts) * Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Product (the application artifacts) Software Engineering Product – the artifacts Design model a document in UML, for example Source code program and object code Software requirements specification a document in legalistic English, and UML, for example Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. comp2110 concerns

What's in the course? comp2110 components ● core content – methods for designing software for a given purpose – technical "design ideas" to use ● at high level ● at detailed level – specifications of requirements for software ● supporting concepts – notational methods for describing software design – notations for specification of requirements – software lifecycle framework – "quality" – what makes it a good design (or not)

What's in the course? comp2110 components (2) ● core content: methods, design ideas, specification ● supporting concepts: notations, framework, quality ● not what you might have hoped for: – not user interface design – a specialised topic ● not what you might have feared: – not rigid "methodology" or recipes for cookbook design ● develops your skills in doing design by making descriptions and by criticising existing designs

COMP2110 Organisation ● people ● lectures ● tutorials and laboratories ● textbook ● assignments ● exam ● assessment scheme

COMP2110 course organisation (1) ● people – Chris Johnson & Ian Barnes – Tamiru Jarso, Terence Tan, Michael Still ● lectures see course website for the plan – 3 in week 1 only 2 in most other weeks: total 24 ● tutorials and laboratories see course website – every week – important for practising and learning ● textbook Eric Braude, Software Design the green book

COMP2110 course organisation (2) ● assignments 1) criticise and create requirements 2) in pairs: create requirements, criticise existing design, start creating project design Pairs will make 1 presentation and submit 1 report. 3) individual: detailed design and modified requirements for project ● final exam: yes ● assessment scheme details: Friday 25 July