Introduction

CSC 440: Engineering Slide #1 Topics

1. What is ? 2. Software Engineering Life Cycles 3. The 4. The (UP) 5. Object-Oriented Analysis and Design

CSC 440: Software Engineering Slide #2 What is Software Engineering?

An engineering discipline concerned with all aspects of the software development process  Specification  Design  Implementation  Testing  Deployment  Maintenance

CSC 440: Software Engineering Slide #3 Participants in Software Development

CUSTOMER Sponsors system development

$$$, DEVELOPER needs

USER Contractual Uses obligation Builds system system Needs

Software system

CSC 440: Software Engineering Slide #4 Why Software Engineering?

 Writing a program is easy  Developing a software product is hard

CSC 440: Software Engineering Slide #5 Software—A Risky Business

•All based on Not waterfall lifecycle. Compl eted •53% cost almost 30% 200% of original estimate. •Estimated $81 Compl eted billion spent on 70% failed U.S. projects in 1995. Source: Standish Report, 1994

CSC 440: Software Engineering Slide #6 Software Life Cycles Waterfall Model  Early model of software engineering derived from hardware manufacturing  Each stage produces a product, which is consumed by next stage  No going backwards Unified Process  Iterative model, permitting feedback from later steps of an iteration to earlier steps of the next iteration

CSC 440: Software Engineering Slide #7 Why do we need a process?

People are more important than any process.

Good people with a good process will outperform good people with no process every time. -- Grady Booch

CSC 440: Software Engineering Slide #8 Waterfall Model

Requirements

Design

Coding

Testing

Maintenance

CSC 440: Software Engineering Slide #9 Waterfall Model

1. Requirements  Eliciting product features needed by customer and encoding them in a precise format 2. Design  Creating a solution for the problem defined in the Requirements process 3. Coding  Implementing the design as a software product 4. Testing  Verifying the correctness of the implementation 5. Maintenance  Fixing bugs and adapting the product to new requirements

CSC 440: Software Engineering Slide #10 Impact of Risks

100

80

60

40

20 Relative Impact of Risks Confronted of Impact Risks Relative

CSC 440: Software Engineering Slide #11 Waterfall Model Problems

 Faulty Assumptions  Requirements can be fairly accurate  Requirements are stable  Design can be done before coding  Large steps  No feedback  Heavy process  Many artifacts created to rigidly predict and control software development in a bureaucratic environment

CSC 440: Software Engineering Slide #12 Solutions Iterative and incremental development  Small steps  Feedback and adaptation  Progressive refinement and enlargement  Early models  V Model  Boehm’s Agile process  Lightweight, adaptive development process that creates only artifacts necessary for the project  Based on principles of the Agile Manifesto  Examples: UP, XP, SCRUM

CSC 440: Software Engineering Slide #13 Feedback and Adaptation

Early iterations are farther from the "true path" of the system. Via feedback and In late iterations, a significant change in adaptation, the system converges towards requirements is rare, but can occur. Such the most appropriate requirements and late changes may give an organization a design. competitive business advantage.

one iteration of design, implement, integrate, and test

CSC 440: Software Engineering Slide #14 The Unified Process

Iterative and incremental development process  Each iteration includes requirements, design, implementation, and test activities  Each iteration produces a working partial system  Customer feedback on partial system alter requirements, so final system meets customer needs  Iterations are timeboxed: 2-8 weeks  Address high risk aspects in early iterations Created by Rational Software (now IBM)

CSC 440: Software Engineering Slide #15 UP Iterations

Requirements Requirements Feedback from iteration N leads to Design Design refinement and Time adaptation of the Implementation & Implementation & requirements and Test & Integration Test & Integration design in iteration & More Design & More Design N+1.

Final Integration Final Integration & System Test & System Test

4 weeks (for example) Iterations are fixed in The system grows length, or timeboxed. incrementally.

CSC 440: Software Engineering Slide #16 UP Schedule and Phases

Schedule organized into 4 phases  Each phase consists of one or more iterations  Phases different from Waterfall Model Phases UP Phases  Inception  Elaboration  Construction  Transition

CSC 440: Software Engineering Slide #17 UP Schedule

development cycle

iteration phase

inc. elaboration construction transition

milestone release increment final production release An iteration end- A stable executable The difference point when some subset of the final (delta) between the At this point, the significant decision product. The end of releases of 2 system is released or evaluation occurs. each iteration is a subsequent for production use. minor release. iterations.

CSC 440: Software Engineering Slide #18 Inception Phase Entry Criteria  Need for project: original vision, legacy system, mock-up Activities  Formulate scope of project  Develop risk mitigation strategy  Develop initial project plan with cost/schedule tradeoffs  Prepare project environment Exit Criteria  Product vision, containing core requirements  Success criteria  Initial risk assessment  Estimate of required resources for elaboration phase

CSC 440: Software Engineering Slide #19 Elaboration Phase

Entry Criteria  Exit criteria artifacts from last iteration  Plan approved by and funding authority  Required resources allocated Activities  Define the core architecture  Validate the architecture  Baseline the architecture, addressing high risk items  Refine requirements Exit Criteria  Construction Phase plan, with number and contents of each iteration  Development environment and tools  Domain analysis model  Executable architecture baseline

CSC 440: Software Engineering Slide #20 Construction Phase

Entry Criteria  Exit criteria artifacts and products from last iteration  Risks being mitigated during this iteration  Defects being fixed during this iteration Activities  Develop and test software components to satisfy use cases and nonfunctional requirements  Manage resources and control process  Assess the iteration Exit Criteria  Updated versions of artifacts  Iterative implementation of remaining lower risk elements  Test cases and test results for iteration’s products  Iteration plan for next iteration  Measurable evaluation criteria for assessing next iteration’s results

CSC 440: Software Engineering Slide #21 Transition Phase Entry Criteria  Exit criteria artifacts from last iteration  A software product mature enough to beta test Activities  Test software product in customer environment  Fine tune product based on customer feedback  Deliver final product to customer  Finalize end-user support documents Exit Criteria  Update of previous documents as necessary  “Post-mortem” analysis of project relative to original and revised success criteria

CSC 440: Software Engineering Slide #22 UP Disciplines Discipline: set of activities and artifacts in one subject area  Requirements: requirements analysis, including writing use cases and identifying non-functional requirements  Design: , responsibility assignment to objects, database design, etc.  Implementation: programming and building the system  Test: unit tests for individual classes, integration tests for putting classes together, and acceptance tests by customers  Environment: setting up tool and process environment for software development

CSC 440: Software Engineering Slide #23 Disciplines across Iterations

A four-week iteration (for example). A mini-project that includes work in most Note that disciplines, ending in a stable executable. although an iteration includes work in most Sample disciplines, the UP Disciplines relative effort and emphasis change Business Modeling over time. Focus of this Requirements This example is book suggestive, not Design literal. Implementation

Test

Deployment

Configuration & Change Management

Project Management

Environment

Iterations

CSC 440: Software Engineering Slide #24 UP Variants

Agile Unified Process (AUP)  Lightweight variant  Succeeded by Disciplined Agile Delivery (DAD) Open Unified Process (OpenUP)  Used to develop Eclipse Framework Oracle Unified Method (OUM)  Oracle development process Rational Unified Process (RUP)  IBM/Rational software development process

CSC 440: Software Engineering Slide #25 Object-Oriented Analysis & Design Analysis  Investigation of the problem and requirements, with an emphasis on finding and describing the objects (or concepts) in the problem domain  ex: a library information system would include domain objects like Book, Library, or Patron Design  Creating a conceptual solution that fulfills the requirements by defining software objects and how they collaborate to fulfill the requirements  ex: the Book object may have a title attribute and getChapter method

CSC 440: Software Engineering Slide #26 Object-Oriented Analysis & Design Requirements Analysis  Before OOA/D, write use cases to capture requirements Assigning Responsibilities  The most important skill in OOA/D is assigning responsibilities to objects Design Patterns  Named problem-solution formulas that codify best practices for object-oriented design UML  Standard diagramming notation used to visually represent objects and their interactions

CSC 440: Software Engineering Slide #27 OOA/D Example: Dice Game

Dice Game Example  Player rolls two dice  If total is 7, player wins  Otherwise, player loses

CSC 440: Software Engineering Slide #28 Use Cases

Use Case: Play a Dice Game  A player picks up and rolls two dice.  If the dice face value total is 7, player wins.  Otherwise, player loses.

CSC 440: Software Engineering Slide #29 Domain Model

OO Analysis  Create description of

problem domain in P la y e r D ie 1 R o lls 2

terms of classifications n a m e fa c e V a lu e

of objects 1 2

 Identify important P la y s concepts, attributes, 1

D ic e G a m e and associations 1 In c lu d e s

CSC 440: Software Engineering Slide #30 Interaction Diagram OO Design  Defining software objects and their :D ic e G a m e d ie 1 : D ie d ie 2 : D ie collaborations p la y ()  Note that while in the ro ll( ) real world a Player rolls the dice, in the design, fv1 := getFaceValue()

the DiceGame object ro ll( ) rolls the dice by sending messages to Die objects fv2 := getFaceValue()  Object design is not generally a direct model of the real world

CSC 440: Software Engineering Slide #31 Design Class Diagram

Interaction diagram provides a dynamic view of collaborating objects

D ic e G a m e D ie

1 2 d ie 1 : D ie faceValue : int Design class diagram d ie 2 : D ie getFaceValue() : int provides a static view p la y () ro ll()  Attributes  Methods  Containment

CSC 440: Software Engineering Slide #32 Architectural Layers

minor focus Interface explore how to connect to other layers

primary focus of application case study logic and Sale Payment domain object explore how to layer design objects

secondary focus technical Log PersistenceFacade services layer explore how to design objects

CSC 440: Software Engineering Slide #33 Iterative Learning & Development

 Book organized in three iterations.  Each iteration delivers a product to the customer.  First iteration has core features.  Second and third elaborate.  Each iteration of book introduces analysis and design skills relevant to current iteration of software product

CSC 440: Software Engineering Slide #34 Key Points

1. The RUP is an agile, iterative process for developing software products 2. RUP schedule divided into 4 phases of 1+ iterations each: 1. Inception 2. Elaboration 3. Construction 4. Deployment 3. Write use cases to capture requirements. 4. The most important skill in OOA/D is assigning responsibilities to objects 5. Design patterns are named problem-solution formulas that codify best practices for object-oriented design 6. UML is the standard visual notation for object modeling.

CSC 440: Software Engineering Slide #35