Software Engineering Summary James Gain

Overview lSummarize:  The Nature of Software Engineering  Analysis  Design  Testing  Methodology  Metrics  Teams  Project Planning

The Nature of Software lSoftware is a set of items or objects forming a “configuration” that includes:  Programs  Documents  Data lSoftware Characteristics:  Complexity  Conformity (to existing systems)  Changeability  Invisibility (difficult to visualize)

Process Models ModelStrengthsWeaknesses Build-and-Fix (hacking) Fine for short programs not needing maintenance Inappropriate for nontrivial programs Waterfall (linear) Disciplined approach Document driven Final product may not meet client’s real needs Prototyping (mock-ups) Helps to detail user’s requirements The prototype may outlive its usefulness IterativeGet early results Promotes maintenance May degenerate into CABTAB Spiral (phases with Risk Anal) Incorporates features from other models Only suited to large-scale in-house development Component- based (OO Re-use) Supports re-use and iteration Expensive in the short term

Analysis analysis designcodetest ProcessModel Output 1. Elicit customer requirements and identify use-cases Use-Case Diagrams 2. Extract candidate classes, Identify attributes and methods, Define a class hierarchy Class Responsibility Collaborator (CRC) Cards 3. Build an object-relationship model (structural) Conceptual Class Diagram 4. Build an object-behaviour model (dynamic) Interaction and State Diagrams

Use-Case Diagrams lGraphically shows use-cases, actors and their relationships. Use Case Communication Relationship Actor Analyze Risk Trader Price Deal Capture Deal Valuation Limits Exceeded > Includes Relationship Extends Relationship

CRC Cards class name: Overlay Image class type: Thing class characteristics: abstract, aggregate, sequential, transient responsibilities: collaborators: Place Save Resolution Edge Reference Image Black-and-white image

Class Diagrams Class Association Label Multiplicity

Sequence Diagrams Object Life Line Active Event

State Diagrams stop /ctr := 0stop [user quits] Final State Done Ready Transition Initial Pseudostate Action Event State Guard

Design Summary analysis designcodetest ProcessModel Output 1. Subsystem Design: partition the system into components A Package Diagram 2. Class and Object Design: define class hierarchies Specification Class Diagram 3. Message Design: convert the object-relationship model into a set of class messages Message Descriptions 4. Responsibility Design: specify the internal structure of classes Specification Class Diagram with full attribute and method syntax C++ Class Headers

Package Diagrams Mosaic Image Image Reference Picture Mosaic Generator Package Dependancy

Specification Class Diagrams

Testing Summary analysis designcodetest ProcessTechnique 1. Class Testing: test methods and state behaviour of classes Random, Partition and White-Box Tests 2. Integration Testing: test the interaction of sets of classes Random and Behavioural Testing 3. Validation Testing: test whether customer requirements are satisfied Use-case based black box and Acceptance tests 4. System Testing: test the behaviour of the system as part of a larger environment Recovery, security, stress and performance tests

Methodology lExtreme Programming in a nutshell:  Lightweight: little documentation or administration overhead  Agile: able to adapt quickly to changes in user requirements  Best for small scale projects with uncertain or evolving requirements lXP Style:  Iterative development (about a dozen iterations of 1-3 weeks each) of a complete system on each iteration  Just in time planning (does not plan much beyond the current iteration)  Emphasis on testing (unit tests are written before functionality)  Carefully considers people issues (stand-up meetings, pair programming, no overtime)

Metrics lAttempt to objectively quantify Software Engineering lIn order to characterize, evaluate, predict and improve the process and product a metric baseline is essential lApplication of Metrics: 1.Process: Measure and correct the software process applied by your organization over several projects. Use Function Point normalization to allow comparison across projects 2.Project: Create reliable estimates of time and cost. Track and control the project schedule 3.Product: Monitor and adjust aspects of the software as it is created. Object-oriented SE has specific metrics for analysis, design and coding

Teams OrganizationStrengthsWeaknesses Democratic (DD)Collective code ownership Handles hard problems Cannot be externally imposed May not scale Classical Chief Programmer (CC) Miraculous success with New York Times Impractical Modified Chief Programmer (CC) Scales well Handles strict delivery No successes comparable to New York Times Synchronize and Stabilize (CD) Encourages creativity Scales very well Is it effective outside Microsoft? Extreme Programming (DD) Many - sharing info, group ownership of code, improved quality Not fully proven DD = Democratic Decentralized, CC = Controlled Centralized, CD = Controlled Decentralized

Project Planning lScope—understand the problem and the work that must be done. lEstimation—how much effort? how much time? lRisk—what can go wrong? how can we avoid it? what can we do about it? lSchedule—how do we allocate resources along the timeline? what are the milestones? lControl strategy—how do we control quality? how do we control change? Software Project Plan Project Scope Estimates Risks Schedule Control strategy