310414310414 SOFTWARE DEVELOPMENTSOFTWARE DEVELOPMENT1
SOFTWARE DEVELOPMENT SOFTWARE DEVELOPMENT PROCESSPROCESS
SOFTWARE DEVELOPMENT SOFTWARE DEVELOPMENT PROCESSPROCESS
310414310414SOFTWARE ENGINEERINGSOFTWARE ENGINEERING
310414310414SOFTWARE ENGINEERINGSOFTWARE ENGINEERING
310414310414 SOFTWARE DEVELOPMENTSOFTWARE DEVELOPMENT2
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
310414310414 SOFTWARE DEVELOPMENTSOFTWARE DEVELOPMENT3
SOFTWARE DEVELOPMENT OVERVIEWSOFTWARE DEVELOPMENT OVERVIEW
ProductProject
People
template
participate
result
customersuserssoftware engineers...
set of artifactsmodelscodemanuals...
set of activities(workflows)
Process
userrequirementsApplication
Domain
12.1
310414310414 SOFTWARE DEVELOPMENTSOFTWARE DEVELOPMENT4
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)
310414310414 SOFTWARE DEVELOPMENTSOFTWARE DEVELOPMENT5
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
310414310414 SOFTWARE DEVELOPMENTSOFTWARE DEVELOPMENT6
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
310414310414 SOFTWARE DEVELOPMENTSOFTWARE DEVELOPMENT7
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
310414310414 SOFTWARE DEVELOPMENTSOFTWARE DEVELOPMENT9
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
310414310414 SOFTWARE DEVELOPMENTSOFTWARE DEVELOPMENT11
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
310414310414 SOFTWARE DEVELOPMENTSOFTWARE DEVELOPMENT12
SPIRAL SOFTWARE DEVELOPMENT PROCESSSPIRAL SOFTWARE DEVELOPMENT PROCESS
Planning Risk analysis
Customer evaluation Engineering
Go, no-godecision
Toward acompletedsystem
12.4.3
310414310414 SOFTWARE DEVELOPMENTSOFTWARE DEVELOPMENT13
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
310414310414 SOFTWARE DEVELOPMENTSOFTWARE DEVELOPMENT14
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.
310414310414 SOFTWARE DEVELOPMENTSOFTWARE DEVELOPMENT16
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
310414310414 SOFTWARE DEVELOPMENTSOFTWARE DEVELOPMENT17
PHASED PROCESS — INCREMENTS & PHASED PROCESS — INCREMENTS & ITERATIONSITERATIONS
incremental development –> partial system; full functionality
iterative development –> full system; partial functionality
310414310414 SOFTWARE DEVELOPMENTSOFTWARE DEVELOPMENT19
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.
310414310414 SOFTWARE DEVELOPMENTSOFTWARE DEVELOPMENT20
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
310414310414 SOFTWARE DEVELOPMENTSOFTWARE DEVELOPMENT21
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
310414310414 SOFTWARE DEVELOPMENTSOFTWARE DEVELOPMENT22
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
310414310414 SOFTWARE DEVELOPMENTSOFTWARE DEVELOPMENT23
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
310414310414 SOFTWARE DEVELOPMENTSOFTWARE DEVELOPMENT24
Inception Elaboration Construction Transition
UNIFIED PROCESS — LIFE CYCLEUNIFIED PROCESS — LIFE CYCLE
PhasesCore Workflows
Requirements
Analysis
Design
Implementation
Testing
310414310414 SOFTWARE DEVELOPMENTSOFTWARE DEVELOPMENT27
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
310414310414 SOFTWARE DEVELOPMENTSOFTWARE DEVELOPMENT28
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
310414310414 SOFTWARE DEVELOPMENTSOFTWARE DEVELOPMENT29
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
310414310414 SOFTWARE DEVELOPMENTSOFTWARE DEVELOPMENT30
• 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”
310414310414 SOFTWARE DEVELOPMENTSOFTWARE DEVELOPMENT31
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
310414310414 SOFTWARE DEVELOPMENTSOFTWARE DEVELOPMENT32
ARCHITECTURE — ANALYSIS MODEL (CLASSES)ARCHITECTURE — ANALYSIS MODEL (CLASSES)
BankCustomer
Dispenser
Withdrawal Account
CashierInterface
Withdraw moneyBankCustomer
310414310414 SOFTWARE DEVELOPMENTSOFTWARE DEVELOPMENT33
ARCHITECTURE — ANALYSIS MODEL (PACKAGES)ARCHITECTURE — ANALYSIS MODEL (PACKAGES)
«package»
ATMInterface
«package»
AccountManagement
«package»
TransactionManagement
BankCustomer
310414310414 SOFTWARE DEVELOPMENTSOFTWARE DEVELOPMENT34
ARCHITECTURE — DESIGN MODEL (CLASSES)ARCHITECTURE — DESIGN MODEL (CLASSES)
Account
Card Reader
Display
Key Pad
DispenserFeeder
DispenserSensor
ClientManager
CashCounter
TransactionManager
Withdrawal
AccountManager
PersistentClass
BankCustomer
310414310414 SOFTWARE DEVELOPMENTSOFTWARE DEVELOPMENT35
ARCHITECTURE — DESIGN MODEL (SUBSYSTEMS)ARCHITECTURE — DESIGN MODEL (SUBSYSTEMS)
«subsystem»
ATMInterface
BankCustomer
dispensing
withdrawal
transactions
«subsystem»
AccountManagement
«subsystem»
TransactionManagement
310414310414 SOFTWARE DEVELOPMENTSOFTWARE DEVELOPMENT36
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»
310414310414 SOFTWARE DEVELOPMENTSOFTWARE DEVELOPMENT37
ARCHITECTURE — DEPLOYMENT MODELARCHITECTURE — DEPLOYMENT MODEL
BankCustomer
intranet ATMApplication
Server
ATMClient
ATMData
Server
internet
310414310414 SOFTWARE DEVELOPMENTSOFTWARE DEVELOPMENT38
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
310414310414 SOFTWARE DEVELOPMENTSOFTWARE DEVELOPMENT39
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
310414310414 SOFTWARE DEVELOPMENTSOFTWARE DEVELOPMENT44
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