310414 SOFTWARE DEVELOPMENT 1 SOFTWARE DEVELOPMENT PROCESS 310414 SOFTWARE ENGINEERING 310414...

310414310414 SOFTWARE DEVELOPMENTSOFTWARE DEVELOPMENT1

SOFTWARE DEVELOPMENT SOFTWARE DEVELOPMENT PROCESSPROCESS

SOFTWARE DEVELOPMENT SOFTWARE DEVELOPMENT PROCESSPROCESS

310414310414SOFTWARE ENGINEERINGSOFTWARE ENGINEERING

310414310414SOFTWARE ENGINEERINGSOFTWARE ENGINEERING


SOFTWARE DEVELOPMENT PROCESS OUTLINESOFTWARE DEVELOPMENT PROCESS OUTLINE

Overview of Software Development Processes– code-and-fix

– waterfall

– prototyping

– fourth generation

– spiral

– phased

Unified Software Development Process (UP)– life cycle

– use-case and risk driven

– architecture-centric

– iterative and incremental

12


SOFTWARE DEVELOPMENT OVERVIEWSOFTWARE DEVELOPMENT OVERVIEW

ProductProject

People

template

participate

result

customersuserssoftware engineers...

set of artifactsmodelscodemanuals...

set of activities(workflows)

Process

userrequirementsApplication

Domain

12.1


WHY IS PROCESS IMPORTANT IN SOFTWARE WHY IS PROCESS IMPORTANT IN SOFTWARE DEVELOPMENT?DEVELOPMENT?

Allows division of labour easier for each team member to know what to do

Promotes teamwork/individual work/communication understand what others are doing (over time, among projects, etc.)

Eases project management supervisors/managers can understand what is happening

Allows expertise reuse/reassignment transfer among projects more easily (developers, managers, etc.)

Eases training can be standardized (e.g., courses)

Promotes productivity/better development development becomes repeatable (e.g., schedule/cost estimates)


SOFTWARE DEVELOPMENT PROCESSSOFTWARE DEVELOPMENT PROCESSA MANAGEMENT VIEWA MANAGEMENT VIEW

definition phase focus is on WHAT– project planning– requirements gathering– analysis

development phasefocus is on HOW– design – testing– coding –

deployment

maintenance phase focus is on CHANGE– bug fixes –

adaptation– enhancements

plus deliverables, reviews, change control, . . .

methods (activities)– provide technical “how to's”

for building software

methodology (workflow)– sequence in which methods

will be applied– deliverables required– controls needed to ensure

quality and coordinate change

– milestones to assess progress

tools (support)– provide automated or semi-

automated support for methods

AN ENGINEERING VIEWAN ENGINEERING VIEW


CODE-AND-FIX SOFTWARE DEVELOPMENT PROCESSCODE-AND-FIX SOFTWARE DEVELOPMENT PROCESS

process: write code, fix errors, enhance functionality

many changes code structure becomes messy, hard to fix

not suitable for large system development because:– turnover of personnel

– difficult to fix code

– user requirements can easily be unmatched

development becomes:– unpredictable

– uncontrollable

– over schedule, over budget, low quality

more structured software development process needed


WATERFALL SOFTWARE DEVELOPMENT PROCESSWATERFALL SOFTWARE DEVELOPMENT PROCESS

plus: reviews (correctness, standards), deliverables(documentation, code), training material, . . .

produces a requirements specification document

produces a design specification document

produces an implementedcollection of modules

produces a testedassembly of modules

keeps the systemworking andup-to-date

Analysis

Design

Coding

Testing

Maintenance

12.4.1


GatherRequirements& Refine

QuickDesign

BuildPrototype

CustomerEvaluation ofPrototype

RefinePrototype

EngineerProduct

PROTOTYPING SOFTWARE DEVELOPMENT PROCESSPROTOTYPING SOFTWARE DEVELOPMENT PROCESSStart

Stop basically a code-and-

fix process BUT ...

useful when requirements are vague or unknown– explore user interface

– explore functionality needed

incremental development and delivery

What to do with the final prototype?

12.4.4; 12.4.5


FOURTH GENERATION (4G) SOFTWARE FOURTH GENERATION (4G) SOFTWARE DEVELOPMENT PROCESSDEVELOPMENT PROCESS

4G tools:– database query language– report generator– screen painter– charting/graphing tools– spreadsheet– application generator

Implementationusing 4G tools

Testing

Requirementsgathering

“Design”strategy


SPIRAL SOFTWARE DEVELOPMENT PROCESSSPIRAL SOFTWARE DEVELOPMENT PROCESS

Planning Risk analysis

Customer evaluation Engineering

Go, no-godecision

Toward acompletedsystem

12.4.3


SPIRAL PROCESS — RISKSSPIRAL PROCESS — RISKS

RISKRISKanything that anything that endangersendangers or or eliminates successeliminates success for a project for a project

RISKRISKanything that anything that endangersendangers or or eliminates successeliminates success for a project for a project

Non-technical risks– right expertise– training– schedule– approvals

Technical risks– building the right system– system architecture– new technologies– performance

Dealing with risksDealing with risks– avoid– confine– mitigate– monitor

GOALGOAL: deal with biggest risks as early as possible


QUESTION?QUESTION?

The greatest risk that you have to deal with in your course project is:

1) not knowing how to work together as a team.

2) not knowing how to use Visual Basic.

3) not knowing how to use Microsoft Access.

4) falling asleep during the lecture.

5) not knowing the exact requirements for the system.

6) not having enough time to finish the project.


PHASED SOFTWARE DEVELOPMENT PROCESSPHASED SOFTWARE DEVELOPMENT PROCESS

Build release 1 Build release 2 Build release 3

Use release 1 Use release 2 Use release 3

TimeDev

elop

ers

Use

rs


PHASED PROCESS — INCREMENTS & PHASED PROCESS — INCREMENTS & ITERATIONSITERATIONS

incremental development –> partial system; full functionality

iterative development –> full system; partial functionality


CASE STUDY: A BUDGET CONTROL SYSTEMCASE STUDY: A BUDGET CONTROL SYSTEM

Problem: Build a software system for a small, high-tech software consulting and development company that monitors whether the financial transactions involved in the various software projects are proceeding according to the original budgets.

take corrective action early if not on track

Scenario: The budget control activity often needs to be customized to the particular activities of an organization. While the

budget control activity is related to other administrative activities, (e.g., payroll processing, income and expense monitoring, etc.), unlike these, budget control is based both on objective data, such as time and costs, and on subjective data, such as estimates of the value of the "work in progress". Since staff may be involved in several projects simultaneously, and there is no log about their contribution to each project, it is hard to assign costs to each project.


CASE STUDY: A BUDGET CONTROL SYSTEMCASE STUDY: A BUDGET CONTROL SYSTEM

Initial findings

Real problem is not budget control per se, but understanding what it is with respect to this company.

The current administrative system is not suitable for providing the data required by budget control.

Difficulties of developing a budget control system are related to:– unusual nature of the activities of the company (not standard)

– lack of standard production rules

– need to re-schedule and re-budget most activities

– personnel turnover

a precise statement of requirements is not possible


QUESTIONQUESTION

Which of the following software development processes, or combinations of processes, would you use to develop the Budget Control System? Why?

– code-and-fix– waterfall– prototyping– fourth generation– spiral– phased


abstraction and generality allows us to concentrate on

important aspects and to possibly reuse software

rigor and formality allows us to repeat what we

have done and to produce better quality software

separation of concerns and modularity allows us to divide

responsibilities/work and to work on parts independently

SOFTWARE DEVELOPMENT PROCESS —SOFTWARE DEVELOPMENT PROCESS —BEST PRACTICESBEST PRACTICES

risk assessment allows us to deal with

project threatening issues first

anticipation of change allows us to prepare for

maintenance

incremental development allows us to evolve to

the desired solution

IncorporatingIncorporating best practicesbest practices leads to good/appropriate leads to good/appropriate methodologiesmethodologies and and toolstools for software engineering for software engineering

IncorporatingIncorporating best practicesbest practices leads to good/appropriate leads to good/appropriate methodologiesmethodologies and and toolstools for software engineering for software engineering


UUNIFIED SOFTWARE DEVELOPMENT NIFIED SOFTWARE DEVELOPMENT PPROCESS (UP)ROCESS (UP)

Selects from best practices to:

use-case and risk drivenuse-case and risk driven

architecture-centricarchitecture-centric

iterative and incrementaliterative and incremental

provide a generic process framework instantiate/specialize for specific application areas, organizations,

project sizes, etc.

define a set of activities (workflows) transforms users’ requirements into a software system

define a set of models from abstract (user-level) to concrete (code)

allow component-based development software components interconnected via well-defined interfaces

12.4.6


Inception Elaboration Construction Transition

UNIFIED PROCESS — LIFE CYCLEUNIFIED PROCESS — LIFE CYCLE

PhasesCore Workflows

Requirements

Analysis

Design

Implementation

Testing


UNIFIED PROCESS — USE-CASE DRIVENUNIFIED PROCESS — USE-CASE DRIVEN

actor: represents the users

use case: a piece of functionality required by an actor

use-case model: the complete system functionality (all use cases)

use-case model represents all system user functionality(functions that add value for the users)

use-case model is used to reach agreement with the customer on the system’s required functionality

(it represents a contract between customer and developer)

use cases drive the development process(we transform the use case model into analysis,

design and implementation models)

supports seamless traceabilitytraceability between models


UNIFIED PROCESS EXAMPLE — USE-CASE MODELUNIFIED PROCESS EXAMPLE — USE-CASE MODEL

A bank customer uses an ATM to withdraw and deposit moneyfrom and to accounts and to transfer money between accounts.

BankCustomer

Withdraw money

Deposit money

Transfer betweenaccounts

Use-case model

Analysis model

Design model

Deployment model

Implementation model

Test model


UNIFIED PROCESS — ARCHITECTURE-CENTRICUNIFIED PROCESS — ARCHITECTURE-CENTRIC

architecturearchitecture:: the the strategic decisionsstrategic decisions about a system that are about a system that are applied applied consistentlyconsistently and and pervasivelypervasively throughout the system throughout the system

architecturearchitecture:: the the strategic decisionsstrategic decisions about a system that are about a system that are applied applied consistentlyconsistently and and pervasivelypervasively throughout the system throughout the system

WHAT

HOW

GOALGOAL –> a stable architecture early in the development

represents the most significant static and dynamic aspects of the system (subsystems, interfaces, dependencies, etc.)

provides different views of the system

describes the foundation of the system

key use cases (normally 5-10%) determine the architecture

use cases describe the function of the system

architecture describes the form of the system


• previous architecture• architecture patterns

DETERMINING ARCHITECTUREDETERMINING ARCHITECTURE

ArchitectureArchitecture

drive guides

--> object broker, client/server, layers, etc.

Use casesUse cases

ExperienceExperience

Constraints & Enablers

System software

Middleware

Legacy systems

Standards & policies

Non-functional requirements

Distribution needs

architecture baseline: a skeleton of the system with all critical parts, but with few software “muscles”


ARCHITECTURE — USE-CASE MODELARCHITECTURE — USE-CASE MODEL

A bank customer uses an ATM to withdraw and deposit moneyfrom and to accounts and to transfer money between accounts.

BankCustomer

Withdraw money

Deposit money

Transfer betweenaccounts


ARCHITECTURE — ANALYSIS MODEL (CLASSES)ARCHITECTURE — ANALYSIS MODEL (CLASSES)

BankCustomer

Dispenser

Withdrawal Account

CashierInterface

Withdraw moneyBankCustomer


ARCHITECTURE — ANALYSIS MODEL (PACKAGES)ARCHITECTURE — ANALYSIS MODEL (PACKAGES)

«package»

ATMInterface

«package»

AccountManagement

«package»

TransactionManagement

BankCustomer


ARCHITECTURE — DESIGN MODEL (CLASSES)ARCHITECTURE — DESIGN MODEL (CLASSES)

Account

Card Reader

Display

Key Pad

DispenserFeeder

DispenserSensor

ClientManager

CashCounter

TransactionManager

Withdrawal

AccountManager

PersistentClass

BankCustomer


ARCHITECTURE — DESIGN MODEL (SUBSYSTEMS)ARCHITECTURE — DESIGN MODEL (SUBSYSTEMS)

«subsystem»

ATMInterface

BankCustomer

dispensing

withdrawal

transactions

«subsystem»

AccountManagement

«subsystem»

TransactionManagement


CashCounter

ARCHITECTURE — IMPLEMENTATION MODELARCHITECTURE — IMPLEMENTATION MODEL

DispenserFeeder

DispenserSensor

ClientManager

«executable»

client.exe

Design Model Implementation Model

«file»

client.c

«file»

dispenser.c

«resides»

«resides»

«compilation»

«compilation»

«resides»

«resides»


ARCHITECTURE — DEPLOYMENT MODELARCHITECTURE — DEPLOYMENT MODEL

BankCustomer

intranet ATMApplication

Server

ATMClient

ATMData

Server

internet


UNIFIED PROCESS — ITERATIVE & INCREMENTALUNIFIED PROCESS — ITERATIVE & INCREMENTAL

iteration: a step through the workflowsincrement: growth in the product

each increment establishes a new baseline for the system

iterations/increments must be controlled to be effective

developing the system in small steps allows us to:– mitigate risks – plan better– develop a robust architecture – integrate subsystems more

easily– get feedback – attain early learning

How to select what to put in an iteration?

1. use cases that extend product usability

2. highest risk use cases


UNIFIED PROCESS — MILESTONESUNIFIED PROCESS — MILESTONES

milestonemilestone:: a a management decision pointmanagement decision point in a in a project project that determines whether to that determines whether to authorize authorize

movement to the next iteration/phasemovement to the next iteration/phase

milestonemilestone:: a a management decision pointmanagement decision point in a in a project project that determines whether to that determines whether to authorize authorize

movement to the next iteration/phasemovement to the next iteration/phase

Inception phase — agreement among customers/developers on the system’s life cycle objectives

Elaboration phase — agreement on the viability of the life cycle architecture, business case and project plan

Construction phase — agreement on the acceptability of the software product both operationally and in terms of cost

Transition phase — final agreement on the acceptability of the software product


Inception Elaboration Construction Transition

UNIFIED PROCESS — LIFE CYCLE (revisited)UNIFIED PROCESS — LIFE CYCLE (revisited)

PhasesCore Workflows

Requirements

Analysis

Design

Implementation

Testing

iter.#1

iter.#2

— — — — —iter.#n-1

iter.#n

incrementmajor milestone

Iter

atio

n

Date post:	27-Dec-2015
Category:	Documents
Upload:	clifton-harris
View:	248 times
Download:	1 times

310414 SOFTWARE DEVELOPMENT 1 SOFTWARE DEVELOPMENT PROCESS 310414 SOFTWARE ENGINEERING 310414...

Documents