Overview of 219341 software specification and design
1 / 65

Overview - PowerPoint PPT Presentation

  • Updated On :

Overview of 219341: Software Specification and Design. What We Want. Need or Idea. Software. source: Bruegge, Object-oriented Software Engineering. Why can't we just write the program?. The Problem.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Overview' - KeelyKia

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Overview of 219341 software specification and design l.jpg

Overview of 219341:Software Specification and Design

What we want l.jpg
What We Want

Need or Idea


source: Bruegge, Object-oriented Software Engineering

The problem l.jpg
The Problem

"Programming is fun, but developing quality software is hard. In between the nice ideas, the requirements or the "vision", and a working software product, there is much more than programming.

Analysis and design, defining how to solve the problem, what to program, capturing this design [...], review, implement, and evolve is what lies in the core of this book."

[Forward to textbook by Philippe Kruchten]

Intrinsic complexity of software l.jpg
Intrinsic Complexity of Software

About the future of software development...

"There is no singledevelopment, in either technology or in management technique, that by itself promises even one orderofmagnitude improvement in productivity, in reliability, in simplicity."

"No Silver Bullet" by Frederick Brooks. Computer, 1987

See also page 5-6 for Brooks comments about object-oriented approach.

Topics covered in this course l.jpg
Topics Covered in this Course

  • The Software Development Process and Life Cycle Models

  • Software Process for Requirements and Design

  • Iterative & Evolutionary Approach to Software

    • Emphasis on Analysis, Specification, and Design

Specific topics 1 l.jpg
Specific Topics (1)

  • Creating a Vision

  • Discovering and Documenting Requirements

  • Analysis and Modeling

    • Analyze Requirements

    • Domain Modeling

    • Implementation Modeling

    • UML as visual modeling tool

  • Documentation: project, process, and many others

Specific topics 2 l.jpg
Specific Topics (2)

  • Design a solution

    • Principles to guide design decisions

    • Design Patterns

  • Iteratively implementing and refining requirements

  • Validation: testing and reviews

  • Risk as key to avoiding project failure

  • Technology & Tools

    • issue tracking

    • version control

    • documenting change and rationale

Patterns and standards l.jpg
Patterns and Standards

  • We use Patterns to...

    • apply knowledge learned by others, avoid mistakes

    • don't rediscover what is already known

    • "knowledge reuse"

  • We use Standards to...

    • apply software process knowledge learned by others

    • avoid omissions and mistakes

    • make projects more repeatable and predictable

    • recipes for "best practices"

Where does this course fit in l.jpg
Where Does This Course Fit In?

  • Software Specification & Design

  • Software Verification & Validation

  • Software Testing

  • Project Management

  • Software Processes & Quality Assurance

  • Economics of Software

  • OOP

  • Database, Networking

  • Algorithms & Data Structures

Workflows l.jpg






Imagine you have a software idea l.jpg
Imagine You Have a Software Idea...


  • You are part of a small to medium size software company.

  • You have an idea for a great software product.

    What Do You Do?

  • How do you turn your idea into a project?

  • What are the steps?

    How Will Your Idea Become A Software Project and a Software Product?

Textbooks and readings l.jpg
Textbooks and Readings

Required Textbook:

Craig Larman, Applying UML and Patterns : An Introduction to Object-Oriented Analysis and Design, 3rd Edition, P-H


  • Excellent for O-O Analysis and Design

  • Emphasizes iterative development

  • Author conveys real-world experience


  • Fuzzy about documents and how docs fit together.

  • Bias towards Agile methods; fuzzy about what is a software process.

  • Some gaps you have to research for yourself.

Useful books and resources l.jpg
Useful Books and Resources

  • Martin Fowler, UML Distilled, 3rd Ed. E-book available.

  • Booch, Jacboson, Rumbaugh, The Unified Modeling Language User Guide, 2nd Ed. (more material, but harder to read)

  • Blaha & Rumbaugh, Object-Oriented Modeling and Design with UML, 2nd Ed. Detailed, good insights, but very dense reading.

  • Bruegge & Detoit, Object-Oriented Software Engineering

  • Lethbridge & Laganiere, Object-Oriented Software Engineering, 2nd Ed. (easy to read, good intro to framework concept)

  • Other readings will be assigned from the literature.

Requirements l.jpg

  • Read the assigned material before class each week.

  • Take notes: summarize important points.

  • Participate in discussions.

  • Group project

    • individual roles

    • everyone is developer. everyone is "programmer"

  • Evaluation: exams and quizzes

Project l.jpg

  • Must have a real client

  • Must have a concrete, realistic objective

  • Approved by me

Tentative projects l.jpg
Tentative Projects

  • Program to count stock (inventory) for KU Bookstore.

    Client: KU Bookstore

    Requirements: I don't know

  • LDAP (directory service) web client for CPE.

    Client: me, Aj. Anan

    Requirements: user can view and edit his own profile, change password, search for other people

  • Journal article tracking for KU Engineering Journal.

    Client: Aj. Pirayut, Jim (as proxy)

    Requirements: submit articles online, track the progess of article

Observations from an ske student l.jpg
Observations from an SKE student...

Object-Oriented Programming

This is the most important part if we need to communicate with others in development team, more precisely diagram will ensure everybody agree on same goal, it decrease other problem and risk.

The OOP isn't necessary in detailed, but should focus to unite the concept which everyone understand.

I think drawing technique and communication skill is important here.  For design and analysis, OOP help real world developer, analysis, and system designer more precisely on their task. Many diagrams may be raised in discussion but finally, we got only few 'solid' diagram which team use to implement, or for next discussion.

Observation from ske students l.jpg
Observation From SKE Students...

From SKE students now working in companies...

  • The most important factor for software projects is communication.

  • Imprecise communication leads to many misunderstandings and errors.

  • Visual modeling is helpful for communication.

  • UML diagrams must be accurate to be useful.

  • Lack of documentation makes project more difficult.

Software processes why l.jpg
Software Processes... why?

  • Imagine you are a seniorsoftware engineerat SiamSoft.

  • A person from the sales department comes to you with a custom software project they want to bid on...

Software processes why22 l.jpg
Software Processes... why?

Product Description:

  • A web-based system for buying and selling used electronics, books, cars, CDs, motorcycles, and other items.

  • Registered sellers can login and post item descriptions with digital photos, and price of the item. Items are placed in categories.

  • Anyone can browse available items, but must login in order to buy something.

  • All transactions are cleared through our system, which charges a commission of 4% of the sales price (commission may be changed and may use a sliding scale: lower for high-cost items and frequent sellers).

  • Buyers and sellers can "rate" each other, log complaints, track orders (very limited), and cancel orders (with restrictions).

  • The system must remove "sold" items, cancelled, or old items.

  • This system must be secure.

Software processes why23 l.jpg
Software Processes... why?

The sales person's questions for you are simple:

How much will it cost to build this?

How long will it take?

What personnel (and how many) do you need?

  • Discussion Question:

    How would you go about answering these questions?

    Remember, you're a senior software engineering who has worked on other projects at this company.

Software processes why24 l.jpg
Software Processes... why?

Approaches to answering these questions:

  • look for similar projects your company has done. Use the project data from those.

  • do a rough, high-level architecture design.Then estimate the cost/manpower for each component.

  • apply a cost estimation method such as COCOMO. This may require some preliminary software design.

  • ask an expert......uh, I forgot. youare the expert.

Difficulties l.jpg

  • Client's requirements are not fully known

    • may have non-functional requirements

    • example: require use of a particular database or hardware platform (that you're staff doesn't know)

    • can you identify a non-functional constraint in the description

  • Previous results may not be repeatable

    • if projects are managed ad hoc

    • if organization depends on a few skilled or charismatic individuals

Your goals as software professionals l.jpg
Your Goals as Software Professionals

  • Work for Google.

  • Want to develop useful software that helps the client or user.

  • Want to write/design good quality software that lasts.

  • Make a living (profit) by doing this.

Realities of software l.jpg
Realities of Software

  • Obstacles to writing good software.

  • Change.

  • Useful software is complex.

  • Communication - don't clearly understand what the user(s) want. They don't understand us.

Topics l.jpg

  • Software process models

  • Process iteration

  • Software specification

  • Software design and implementation

  • Software validation

  • Software evolution

  • Automated process & project support

What we want29 l.jpg
What We Want

Need or Idea


source: Bruegge, Object-oriented Software Engineering

Real world software lifecycle l.jpg
Real World Software Lifecycle

  • a need or an idea

  • explore and understand what is needed

  • a vision and business case for the project

  • decision to implement or drop

  • initial prototype.

  • discover more requirements

  • reimplement in greater detail

  • software + architecture design

  • working but buggy software

  • software initial release for use

  • iterative fix bugs and add new features

What is a life cycle model l.jpg
What is a Life Cycle Model

  • A model of the phases that software goes through

  • Serves as a guide for management of software development

  • Model is an abstraction.

    • omits some real-life complexity and detail

Typical lifecycle model l.jpg

Inception of idea


business case







training & education

Typical Lifecycle Model

  • Maintenance and Support

  • End of Support

  • Retirement

    • end of useful life

    • transition or archiving

GREEN = part of the process, not life cycle

Is testing part of the software lifecycle l.jpg
Is Testing Part of the Software Lifecycle?

  • Many people say it is.

  • Or,is testing an activity that is part of many steps in the lifecycle?

How it should go our plan of attack l.jpg






Delivery and Installation

How it should go: Our plan of attack

source: Bruegge, Object-oriented Software Engineering

Why this model doesn t work l.jpg
Why this Model Doesn't Work

  • Requirements aren't complete or accurate.

    • even the client doesn't know precisely

  • Analysis and design aren't accurate.

    • communication issues

    • model not precise

  • Difficult to manage change...

    • technology changes

    • new requirements emerge

    • resource limitations

  • Software consists of many systems

Code and fix l.jpg



repeat as needed






Client Acceptance


This is the implicit process for software development without any formal process model.

Delivery &


Linear development l.jpg





Acceptance Test

Linear Development

  • determine requirements for the product

  • analysis requirements to create a specification.

  • use the specification to construct a software design to satisfy it

  • build it

  • acceptance test by client, followed by delivery and maintenance

Delivery and Maintenance

Waterfall model l.jpg





Acceptance Test

Waterfall Model

The waterfall model recognizes that an activity may uncover a problem from a previous phase.

A previous phase must be reworked to make necessary modifications. This may in turn uncover a problem from its predecessor (i.e. going uphill again).

Delivery and Maintenance

Waterfall loopback in reality l.jpg





Acceptance Test

Waterfall Loopback in Reality

Royce (1970) found that backtracking multiple phases was usually necessary.

The most common backtracking is as shown.

Delivery and Maintenance

Evolutionary development l.jpg







Evolutionary Development

Episode 1

Episode 2

Episode 3

. . .

. . .




Each episode attempts to build a complete product, but the process recognizes the need to repeat the process (in all or part). See Schach, section 2.1.

Iterative and incremental l.jpg
Iterative and Incremental

  • A two-dimensional model: workflows of each increment can overlap.

Miller s law l.jpg
Miller’s Law

  • At any one time, a person can concentrate on at most 7  2chunks (units of information)

  • To handle larger amounts of information, use stepwise refinement

    • Concentrate on the aspects that are currently the most important

    • Postpone aspects that are currently less critical

    • Every aspect is eventually handled, but in order of current importance

  • This is an incremental process

The cost of change l.jpg
The Cost of Change

The cost of detecting and correcting a fault at each phase

Figure 1.5

The cost of change44 l.jpg
The Cost of Change

The previous figure redrawn on a linear scale

Figure 1.6

Incremental development l.jpg
Incremental development

This slide is from Sommerville, Software Engineering.

Do you agree with the activities and flow lines?

Incremental development advantages l.jpg
Incremental development advantages

  • System functionality is available earlier

  • Customer sees value added at each increment

  • Early increments act as a prototype to help elicit requirements for later increments

  • Discover design changes and problems early

  • Lower the risk of overall project failure

  • Highest priority system services tend to receive the most testing

Classical phases versus workflows l.jpg
Classical Phases versus Workflows

  • Sequential phases do not exist in the real world

  • Instead, the five core workflows (activities) are performed over the entire life cycle

    • Requirements workflow

    • Analysis workflow

    • Design workflow

    • Implementation workflow

    • Test workflow

  • Question: why there is a separate test workflow?

Workflows48 l.jpg

  • All five core workflows are performed over the entire life cycle

  • However, at most times one workflow predominates

  • Examples:

    • At the beginning of the life cycle

      • The requirements workflow predominates

    • At the end of the life cycle

      • The implementation and test workflows predominate

  • Planning and documentation activities are performed throughout the life cycle

Iteration and incrementation contd l.jpg
Iteration and Incrementation (contd)

  • For example increment A

    • Determine the requirements

    • After most the requirements have been determined, the first version of the analysis starts

    • Then design

    • Some coding is done

    • Proof-of-concept testing

  • Planning, testing, documentation start on day one

Iteration and incrementation cont d l.jpg
Iteration and Incrementation (cont'd)

  • Iteration is performed during each increment

Schach, Figure 2.5

Iteration and incrementation cont d51 l.jpg
Iteration and Incrementation (cont'd)

  • The number of iterations will vary—it is not always three or four

  • Usual goals:

    • keep iteration duration < 8 weeks

    • add new requirements (e.g. use cases) at each iteration

    • start with the most important use cases

Incorporating risk l.jpg
Incorporating Risk

  • Software development involves risks

    • developer may not be able to complete product according to spec

    • may not be able to meet deadline or budget

    • technology changes

    • personnel may quit, die, ...

    • another product may render the software unmarketable

  • Risk analysis is a part of each phase of a project

  • Minimizing risk can effect design choices

Classical phases vs object oriented workflows l.jpg

Classical Paradigm

Requirements phase

Analysis (Specification) phase

Design phase

Implementation phase

Post-delivery maintenance


Object-Oriented Paradigm

Requirements workflow

O-O Analysis workflow

O-O Design workflow

O-O Implementation workflow

Post-delivery maintenance


Classical Phases vs Object-Oriented Workflows

There is no correspondence between phases and workflows.

Analysis design hump l.jpg
Analysis/Design “Hump”

  • Structured paradigm:

    • There is a jolt between analysis (what) and design (how)

  • Object-oriented paradigm:

    • Objects enter from the very beginning

Analysis design hump cont d l.jpg
Analysis/Design “Hump” (cont'd)

  • In the classical paradigm

    • Classical analysis

      • Determine what has to be done

    • Design

      • Determine how to do it

      • Architectural design — determine the modules

      • Detailed design — data structure and algorithms of each module

Removing the hump l.jpg
Removing the “Hump”

  • In the object-oriented paradigm

    • Object-oriented analysis

      • Determine what has to be done

      • Determine the objects

    • Object-oriented design

      • Determine how to do it

      • Design the objects

  • The difference between the two paradigms is shown on the next slide

Object oriented approach l.jpg

Classical Paradigm

Requirements phase

Analysis (Specification) phase

Design phase

Implementation phase

Post-delivery maintenance


Object-Oriented Paradigm

Requirements workflow

O-O Analysis workflow

O-O Design workflow

O-O Implementation workflow

Post-delivery maintenance


Object-Oriented Approach

Objects enter here

Object oriented paradigm l.jpg
Object-Oriented Paradigm

  • Modules (objects) are introduced as early as the object-oriented analysis workflow

    • This ensures a smooth transition from the analysis workflow to the design workflow

  • The objects are then coded during the implementation workflow

    • Again, the transition is smooth

  • OO is an integrated approach

    • Reduce number of faults introduced in the development

3 1 the unified process l.jpg
3.1 The Unified Process

  • Three of the most successful object-oriented methodologies in the 1990s were:

    • Booch’s method

    • Jacobson’s Objectory

    • Rumbaugh’s OMT

The unified process cont d l.jpg
The Unified Process (cont'd)

  • Gradually Booch, Jacobson, and Rumbaugh combined, unified, their methods. All three ended up at Rational, a company that marketed SE development products.

  • In 1999, Booch, Jacobson, and Rumbaugh published a object-oriented analysis and design methodology that unified their three separate methodologies:

    The Unified Software Development Process

  • Other names : Rational Unified Process (RUP), Unified Process (UP),OpenUP (a new, lighter weight version)

The unified process cont d62 l.jpg
The Unified Process (cont'd)

  • The Unified Process is not a series of steps for constructing a software product

    • No single “one size fits all” methodology exists

    • There is a wide variety of different types of software

  • The Unified Process is an adaptablemethodology

    • It has to be modified for the specific software product to be developed

The unified process l.jpg
The Unified Process

  • is...

    • use-case driven

    • architecture centric

    • iterative

    • incremental

    • object-oriented, usually

  • a multi-dimensional model

    • workflows

    • iterations

Workflows64 l.jpg






What about this course l.jpg
What about this course?

  • The workflows:

    • requirements

    • analysis

    • design

    • implementation

    • testing

    • configuration management

    • project management

    • environment (tools)

    • deployment

emphasis in here

but we also do these