CS 3050

Software Engineering Methodologies

Methodology

Modeling language Graphical notation used to express

the design Process

Guidelines on what steps to take when developing software

Methodology Goals

Establish rules for applying techniques and notations

Establish heuristics for judging when the different stages are complete

Software Development Lifecycle (SDLC)

Describes each step in the process of developing an application

Sets the course and direction of the project

Software Development Lifecycle (SDLC)

Use case driven Establish the desired behavior of the

system Architecture-centric

For conceptualizing, constructing, managing, and evolving the system under development

Software Development Lifecycle (SDLC)

Iterative Managing a stream of executable

releases Incremental

Continuous integration of the system’s architecture to produce these releases. Each new release embodies incremental improvements over the other.

Waterfall Model Waterfall Model

Regarded as the traditional model for Software development - though only described by Royce in 1970

Clearly defined and delineated steps with time-linear progression

Based on the argument that software development is an engineering discipline and can thus be described similarly to other engineering processes

Waterfall Model

RequirementsAnalysis &Definition

System &SoftwareDesign

Implement-ation & Unit

TestingIntegration& SystemTesting

RequirementsAnalysis &Definition

System &SoftwareDesign

Implement-ation & Unit

TestingIntegration& SystemTesting

Operation&

Maintenance

Software LifecycleBased on

Waterfall Model

Exploratory Programming Exploratory Programming

• Developed from early work in A.I.• Used in situations where a specification cannot be

elicited or is very unclear• Similar to prototyping in that it iterates through a

number of development cycles, but it does not attempt to develop a specification

• Validation and verification are impossible• Tends to result in systems with poorly defined

structure, little or no documentation• Difficult to manage due to lack of definable

milestones in development path

Prototyping Prototyping

• Similar to exploratory programming in that it involves starting with the development of a program

• The aim of the developing prototypes is to elicit and clarify a software specification

• Once a specification is established, a more formal devlopment path is followed

• Currently very much in favour in industry, through RAD and DSDM.

Other Methodologies Formal Transformation

• Used in the development of safety-critical software• Define specification in formal notation (i.e. Z),

thereby preserving all correctness properties• Develop program from formal specification, proving

all components of program through formal correctness proofs.

• Longer time-scale trade-off against higher level of reliability

Software Reuse• Assembly of programs from components• Widely-used for interface design, i.e. Visual Basic,

Visual C++, X-Windows, Delphi, etc.

Managing Software Development Managing Software Development

• Various process models are used• Most common technique is “deliverables”• Ongoing support for waterfall model is explicable

in terms of the ease with which “document deliverables” can be generated at strategic points in the development cycle

• Formal transformation provides the most tightly manageable model

• Prototyping and Exploratory Programming are very difficult to manage in this way, since generating documents at each iteration is uneconomic

• Documentation constrains software reuse

Two “must-have” traits in your project

Strong architectural Vision Well managed iterative and incremental development life cycle.

Strong Architectural Vision

Well Defined Abstractions and Interfaces Clear boundaries between implementation and interfaces Simple architecture: Reuse, Super Classes Given: Good architectures tend to be object-oriented!

Development Life-Cycle

Two ways to “drop the ball”:Dictatorship AnarchyRigid, strictly enforced policies No well-defined life cycleDictate each step Can’t predict anything of development InefficientCreativity punishedBureaucracy Lucky to satisfy customerCustomer’s needs not adhered to

End Result: Unsatisfied Customer

Gathering Requirements

Satisfy Functional RequirementsProblem Statement

Why the System is being CreatedTerse and ConciseFree of Technical Jargon

Gathering Requirements

Use Business Objective not Technical ObjectiveTechnical Objective“We need a Web-based OLTP architecture

for our e-commerce application.”

Business Objective"We would like to increase and efficiently

service our customer base by 25%."

Functional Requirements

Group ProcessIdentify a Champion

True customer of the developers

Identify StakeholdersAnyone who can delay or derail projectAll must buy-in

Functional Requirements

Utilize facilitated sessionsEstablish format and rules

Solicit specifications from stakeholdersPrioritize Functionality

Absolutely RequiredEnhances the productNice to have but not crucial

Assessing Requirements

Identify Domain Experts for each feature

Someone highly knowledgeable in the requirements for the function

Produce first artifactDocument capturing all functional requirementsHigh-level view of the system

• Use Case Diagram

“Success” of a projectSatisfies or exceeds customer’s expectationsDeveloped in a timely fashionResilient to Change

Development ProcessControlled, measured, and disciplinedCreative, Innovative

Iterative, IncrementalControl without affecting creativity

The Role of Process

The Software Cycle

Business Modeling

Requirements

Analysis & Design

Implementation

Deployment

Test

The Perspective Cycle

Conceptual

Specification

Implementation

Diagrams represent concepts in the domain under study Concepts relate to classes but no direct mapping No regard for the software that might implement it Language-independent

Conceptual

Focus on interfaces, not implementation

Specification

Mapping to classes is complete

Implementation

UML is process-independent RUP is a development lifecycle

Produce High Quality Software Meet the user’s needs Predictable schedules and budgets

Rational Unified Process

Iterative Maintenance of Models Architecture-Centric Use-Case Driven Object-Oriented Configurable Quality-Control and Risk Management

Rational Unified Process

Phases and Iterations