The document provides an overview of software development processes, focusing on methodologies such as the waterfall model, iterative development, incremental development, and the unified process. It highlights the importance of understanding user requirements, risk management, and iterative improvement in software development. Various models are discussed, detailing their phases, advantages, and disadvantages in building software systems.

1. Business Information Systems
Application Development II
The Development Process
Prithwis Mukerjee, Ph.D.

2. Building Software
 Software Development Life Cycle
 Iterative Software Development
 The Unified Process
Prithwis
Mukerjee 2

3. What is a process ?
A series of steps that specify the way
 Clients
 Analysts
 Designers
 Programmers
 Would work together to create a new system
A process defines Who is doing What, When and How to reach a
certain goal.
 In software engineering the goal is to build a software product or
to enhance an existing one
Various Processes exist
 SDLC Process / Waterfall Method
 Unified Process / Unified Modeling Language
Prithwis
Mukerjee 3

4. System Development Life Cycle
Methodology
Component
Functional Technical
Estimate Develop Deliver Test Support
Design Design
Communication & Coordination
(all teams)
Functional
Functional
Support
USER Driven
Specification
Specification Test
 Client Sign Off
 Client  Client
Review Review Code
Code
Bundle //
Bundle
Demo
Demo
Technical   Code Review
Review Complexity
Complexity Unit Test
Unit Test Unit Test
Unit Test Program
Program Pre-
Pre- Support
Programmer Driven
Determination
Determination Plan
Plan Results
Results Review
Review Production
Production (optional)
// Estimate
Estimate Checklist
Checklist Support
Support
Technical Program
Legend
Technical Program
Specification
Specification Source Code
Source Code Task With Deliverable
 Technical Task Without Deliverable
Design Optional Service Area
Walkthrough
Prithwis
 Process Checkpoint
Mukerjee 4

5. The WaterFall Method – A simplified view
Analysis Users define what they want
from the system
Programmers re-define what they
Design believe the users want in a more
structured manner
Actual program is built using
an appropriate computer Coding
language like C, Java, VisualBasic
Application is tested and then Test / Deploy
deployed in the end users machine
Prithwis
Mukerjee 5

6. The WaterFall Method – Deliverables
Analysis Requirements Analysis Document
written in simple English language
Systems Specifications written in
Design
terms of e.g. TABLES, COLUMNS,
METHODS, FUNCTIONS
Programs written in an appropriate
language and tested individually. Coding
Unit Test Report for each program
All programs tested together to
ensure compatibility and consistency Test / Deploy
Integration Test Report
Prithwis
Mukerjee 6

7. Waterfall Process Assumptions
Requirements are known up front before design
 In reality, users do not know what they want
 They certainly cannot visualise what the final thing will look
like
Requirements rarely change
 They always will, however much you hate it
Design can be conducted in a purely abstract space, or
trial rarely leads to error
The technology will all fit nicely into place when the
time comes (the apocalypse)
Prithwis
Mukerjee 7

8. Waterfall Process Limitations
Big Bang Delivery Theory
The proof of the concept is relegated to the very end of
a long singular cycle. Before final integration, only
documents have been produced.
Late deployment hides many lurking risks:
 technological (well, I thought they would work together...)
 conceptual (well, I thought that's what they wanted...)
 personnel (took so long, half the team left)
 User doesn't get to see anything real until the very end, and
they always hate it.
 System Testing doesn't get involved until later in the process.
Prithwis
Mukerjee 8

9. What did the customer really want ?
Prithwis
Mukerjee 9

10. An Iterative Development Process...
Recognizes the reality of changing requirements
 Caspers Jones’s research on 8000 projects
 40% of final requirements arrived after the analysis phase,
after development had already begun
Promotes early risk mitigation, by breaking down the
system into mini-projects and focusing on the riskier
elements first
 Allows you to “plan a little, design a little, and code a little”
Encourages all participants, including testers, integrators
to be involved earlier on
 Allows the process itself to modulate with each iteration, allowing
you to correct errors sooner and put into practice lessons
learned in the prior iteration
Focuses on component architectures, not final big bang 10
Prithwis
Mukerjee

11. An Incremental Development Process...
Allows for software to evolve, not be produced in one
huge effort
 Allows software to improve, by giving enough time to the
evolutionary process itself
Forces attention on stability, for only a stable
foundation can support multiple additions
 Allows the system (a small subset of it) to actually run much
sooner than with other processes
Allows interim progress to continue through the
stubbing of functionality
Allows for the management of risk, by exposing
problems earlier on in the development process
Prithwis
Mukerjee 11

12. Goals and Features of Each Iteration
The primary goal of each iteration is to slowly chip
away at the risk facing the project, namely:
 performance risks
 integration risks (different vendors, tools, etc.)
 conceptual risks (ferret out analysis and design flaws)
Perform a “mini-waterfall” project that ends with a
delivery of something tangible in code, available for
scrutiny by the interested parties, which produces
validation or correctives
 The result of a single iteration is an increment--an
incremental improvement of the system, yielding an
evolutionary approach
Prithwis
Mukerjee 12

13. Incremental Model
Release 1
Design Coding Test Deployment
Requirements
Release 2
Design Coding Test Deployment
Release 3
Design Coding Test Deployment
Non-incremental, e.g. Waterfall, rapid prototyping models
 Operational quality complete product at end
Incremental model
 Operational quality portion of product within weeks
 Each release adds more functionality, i.e., a new increment
Prithwis
Mukerjee 13

14. Evolutionary Model
Version 1
Requirements Design Coding Test Deployment
Version 1
Requirements Design Coding Test Deployment
Version 1 Feedback
Requirements Design Coding Test Deployment
Advantages
 Constant customer involvement and validation
 Allows for good risk management
Disadvantages
 Build-and-fix danger
 Contradiction in terms
New Mukerjee
versions implement new and evolving requirements14
Prithwis

15. Spiral model
Determine objectives
Evaluate alternatives
alternatives and identify, resolve risks
constraints Risk
analysis
Risk
analysis
Risk
analysis Opera-
Prototype 3 tional
Prototype 2 protoype
Risk
REVIEW anal sis Proto-
y
type 1
Requirements plan Simulations, models, benchmarks
Life-cycle plan Concept of
Operation S/W
requirements Product
design Detailed
Requirem ent design
Development
plan validation Code
Design Unit test
Integration
and test plan V&V Integration
Plan next phase test
Acceptance
Service test Develop, verify
next-level product
Radial dimension: cumulative cost to date
Angular dimension: progress through the spiral
If all risks cannot be resolved, the project is immediately terminated
Prithwis
Mukerjee 15

16. The “Unified Process”
Unified Process (UP) is a methodology proposed by
three amigos: Booch, Jacobson, Rumbaugh
 They are also the co-developers of the Unified Modeling
Language (UML). They formed a company called Rational which
was bought over by IBM
 Non Commercial and Free piece of knowledge
Rational Unified Process
 The proprietory process, based on the Unified Process, along
with a suite of tools that allow one to use the process effectively
 Commercial Product
Prithwis
Mukerjee 16

17. What is UML
Is a language.
 It is not simply a notation for drawing diagrams, but a complete
language for capturing knowledge(semantics) about a subject
and expressing knowledge(syntax) regarding the subject for the
purpose of communication.
Applies to modeling and systems.
 Modeling involves a focus on understanding a subject (system)
and capturing and being able to communicated in this
knowledge.
It is the result of unifying the information systems and
technology industry’s best engineering practices
(principals, techniques, methods and tools).
Prithwis
Mukerjee 17

18. UML – Consists of a set of Artefacts
S St a at e e
tt tte
DDi ai agSgSCraaalaamse s
r t mt s
UUs se e CCa as se e DDi ai ag gr ral amm s s
C as
DDi ai ag gr ra amm s s
DDUaiUUgsgsreraeCmC assassese e
i a e aCm
s a S St a at e e
t t e
UU s se e CC a as se e DD i aiUagsgrera ammas ss e
C DDi ai agSgOtraabatjmee cs t
S t mt s
r
DDUaiUagsgrec Ctmimassissteye
i s Ae ra aCav DD i ai ag gr ra amm s s DDi ai agO rab ame c st
ggrar jamm ss
DDi ai aA grc rataimvmistsy
g DDi ai a g r a m s
DDi ai ag gr ra amm s s
S Sc ce en na ar ri o o S St a at e e
SaSc cer ea nm arisri o o
DDi i Sg g qnauame nsi c e S tStaatat e e
DDi ai ag gr Sr tatmam tse
t
DDaSi eagrgq rauamem n sc e
ia e r s r m ts s
DDi ai ag gS rataa m e s
DD i ai ag gr ra amm s s M odel DDi ai ag gr ra amm s s
S Sc ce en na ar ri o oi
C Co ommp po on ne en nt t
DDiSaioaclcleraerabnmoar sri so ot i o n
S g g na am r a DCiCaoi aomgmar am mnsne en nt t
po
CD ioa lgl ar b m risa t i o n DDe ep pl o oy ymm e en nt t CC ogi ommrppaopm sosn ne en nt t
D D ar g o
CD i a g ra ao m s l D ia g r a m s
DDi ai ag gr ra amm s s DDi ai ag gr ra amm DDi ai ag gr ra amm s s
Prithwis
Mukerjee 18

19. Unified Process : 4 Phases
Inception Construction
 Business case  Iterative implementation of
 Scope lower risk elements
 Vague estimates  Preparation for deployment
 Continue or stop? Transition
Elaboration  Beta tests
 Identification of most  Deployment
requirements
 Iterative implementation of
the core architecture
 resolution of high risks
Inception Elaboration Construction Transition
time Prithwis
Mukerjee 19

20. Iterative and Incremental Development
development is organized into a series of iterations
 short fixed-length mini-projects (2 to 6 weeks)
 timeboxed (i.e. fixed length iterations)
 shift tasks to future iterations if necessary ...
 an iteration represents a complete development cycle
 incl. requirements,
 the outcome of each iteration:
a tested, integrated and executable system
Inception Elaboration Construction Transition
Preliminary Iter. #1 Iter. #2
Iteration
Milestone Release Final production
Prithwis
release
Mukerjee 20

21. 1. Inception Phase
Obtain buy-in from all interested parties
Capture initial requirements
Analyse Cost and Benefits
Analyse Initial Risks
Define Scope of Project
Define candidate architecture
 Language ? RDBMS ? Tiers ?
Develop a disposable prototype
 Look and Feel of the application
Prithwis
Mukerjee 21

22. 2. Elaboration Phase
Define System Requirements
 Develop USE CASE MODELS
 Actors
 USE CASE
 Scenarios
 Use Case Diagrams
 Use Case Descriptions
 Develop Class diagrams
Define Glossary of terms
Refine Risk Assesment
Revised Architecture Document
Prithwis
Mukerjee 22

23. 3. Construction Phase
From paper documents to computer programs
 Cumulative increase in functionality
 Increasing depth of implementation
 Stubs fleshed out
 Implementation of “bells and whistles”

 Increasing severity of testing
 More and more complex test cases
 implement all details, not only those of central architectural
value
Analysis continues, but design and coding
predominate
Prithwis
Mukerjee 23

24. 4. Transition Phase
Transfer of the system to the user community
Includes manufacturing, shipping, installation,
training, technical support and maintenance
Development team begins to shrink
Control is moved to maintenance team
Alpha, Beta, and final releases
Software updates
Integration with existing systems (legacy, existing
versions, etc.)
Prithwis
Mukerjee 24

25. Unified Process Disciplines
Phases
Process Disciplines Inception Elaboration Construction Transition
Business Modeling
Requirements
Design
Implementation
Test
Deployment
Supporting Disciplines
Configuration Mgmt
Management
Environment
Preliminary Iter. Iter. Iter. Iter. Iter. Iter. Iter.
Iteration(s) #1 #2 #n #n+1 #n+2 #m #m+1
Iterations
Prithwis
Mukerjee 25

26. Use Case Model : Actors
Actors will interact with the
system
Product
 Input Information Manager
 Request Information
 Who could be
 Distinct individuals
 Same individual with Salesman
multiple roles
 Other computer systems
Production
Planning
System
Financial
Prithwis System
Mukerjee 26

27. Use Case Models
Define the tasks that the
Actors will pursue Define Product
Product
 for example Manager
 Define a Product
 Define a new Customer
Define Customer
 Create an Order
 List of all Outstanding Orders Salesman
 List of all fulfilled Orders Create Order
Create USE CASE diagram
 UML syntax
 Stick figures - actors Update Order
 Ovals – use cases
 System boundary
 No control on anything Display
Prithwis
outside the system Outstanding
Mukerjee Orders 27

28. Use Case Diagrams
Use Case Diagrams describe the functionality of a
system and users of the system. These diagrams contain
the following elements:
 Actors, which represent users of a system, including human
users and other systems.
 Use Cases, which represent functionality or services provided
by a system to users.
Prithwis
Mukerjee 28

29. Scenarios
A USE CASE could consist of a number of scenarios
 A USE CASE specifies a goal
 Create ORDER, Create Customer
 A SCENARIO represents a particular outcome when attempting
to reach the goal.
 Create Order
 Old customer, good credit rating
 New customer, no credit rating
 Old customer, bad credit rating
 The action to be followed in each case will be different
In a formal development process, each scenario would
have its own documentation describing in detail all the
events in the scenario
Prithwis
Mukerjee 29

30. Use Case Descriptions
Detailed Description of what the USE CASE means
 The USE CASE diagram gives the big picture but does not
provide detailed description of what is happening
Various formats are possible
 Paragraph of text
 Two Column approach
 First column : Actor action
 Second column : System action
 More complexity
 Pre-condition
 Post-condition
 Sequence of steps
 Activity Diagram or Flowchart
 Sequence Diagram
Prithwis
Mukerjee 30

31. Activity Diagram
Display
Order Entry
Screen
Does NO
Customer
exist ?
Define Customer
Order value NO Display
within
Error Message
credit ?
Add Order
Prithwis Record
Mukerjee 31

32. From Use Cases to Classes
“Nouns” in the Use Cases Class Diagram is the
are candidates for connection between
 Classes  Object Oriented
 Order, Customer Programming techniques of
 Attributes the Unified Process and
 Order number, customer id  Data Modelling techniques
that result in Entities and
“Verbs” in the Use Cases
Attributes in Third Normal
are candidates for form
 Methods
Identification of Classes,
Attributes, Methods is an
iterative process
Prithwis
Mukerjee 32

33. Class Diagrams
ORDER CUSTOMER
Order ID N 1 Customer ID
Order Date Customer Name
Customer ID Customer Address
Order Value Customer Credit Limit
Receive, Update, Bill 1 Create, Update,
CreditCheck, ...
ORDER ITEM N PRODUCT
Order ID Product ID
Item ID Product Desc
Product ID N 1 Product unit price
Item quantity Create, SetPrice
Item Deliver Date
Create, Deliver Optional, May Have
Prithwis Mandatory, Must Have
Mukerjee 33

34. Class Diagrams
Class Diagrams describe the static structure of a system,
or how it is structured rather than how it behaves. These
diagrams contain the following elements.
 Classes, which represent entities with common characteristics
or features. These features include attributes, operations and
associations.
 Associations, which represent relationships that relate two or
more other classes where the relationships have common
characteristics or features. These attributes and operations.
Prithwis
Mukerjee 34

35. Sequence Diagram
:Main
Salesman Screen
Start
Challenge : Order
Entry Screen
ID/PW
New
Order Order-Item
New
: Order
Item Screen
New Get Data
New
: Order
Item Screen
New Get Data
New
X
Prithwis
X
Mukerjee 35

36. Sequence Diagrams
Sequence Diagrams describe interactions among
classes. These diagrams focus on classes and the
messages they exchange to accomplish some desired
behavior. Sequence diagrams contain the following
elements:
 Class roles, which represent roles that objects may play within
the interaction.
 Lifelines, which represent the existence of an object over a
period of time.
 Activations, which represent the time during which an object is
performing an operation.
 Messages, which represent communication between objects.
Prithwis
Mukerjee 36

37. UML Diagrams Are Key System Artifacts
Use-Case
Class Diagram State Diagram
Diagram
add file
D o c u m e n t L is t
F il e M g r Do cu m e nt
add( )
n am e : in t
fe tc h D o c ( ) d e lete( )
d o c id : i n t
s o rt B y N am e ( ) n u m F ield : in t
Writing
add file [ numberOffile==MAX ] /
g e t( ) flag OFF
open( ) r e a d () f il l t h e
c lo s e ( ) c o d e ..
F i le L is t re ad ( )
Openning
Use Case 1
s o r t F il e L is t ( )
f Lis t c re a t e ( )
f ill D o c u m e n t ( )
ad d ( )
d e le t e ( )
1 close file
Actor A Actor B
close file
Closing
Reading
Use Case 2
re p
<<entity>>
F il e
R e p o s it o r y
( f r o m P e r s is t e n c e )
rea d ( )
G r p F i le
Customer
name
na m e : ch ar * = 0
re a d ( )
Deployment
addr
re a d D o c ( )
Domain
op en ( )
re a d F il e ( )
c r e a te ( )
receive()
f il lF il e ( )
Use Case 3 withdraw()
fetch()
Expert send()
Diagram
Class
UI
MF C
DocumentApp
ºÐ»ê ȯ°æÀÇ Çϵå¿þ¾î¹× ³×Æ®¿÷À¸· ÎÀÇ Á¤º¸ ½Ã½ºÅÛ ¿¬°á ¸ðµ ¨
­ À©µµ¿ì 95 : Ŭ¶óÀ̾ðÆ®
­ À©µµ¿ì NT: ÀÀ¿ë¼­¹ö
­ À¯´Ð½º ¸Ó½Å: ÀÀ¿ë ¼­¹ö ¹× µ¥ÀÌŸ ¼­¹ö, Åë½Å ¼­¹ö
­ IBM ¸ÞÀÎÇÁ·¹ÀÓ: µ ¥ÀÌŸ ¼­¹ö, Åë½Å ¼­¹ö
RogueWave
Repository DocumentList Windows 95
Window95
9: sortByName ( ) Persistence Windows95
global
FileManager
¹®¼­°ü¸®
Ŭ¶óÀ̾ðÆ®.EXE
¹®¼­° ü¸® ¾ÖÇø´
mainWnd : MainWnd Windows
Package
NT
1: Doc view request ( )
Document
L
Solaris
2: fetchDoc( )
¹®¼­°ü¸® ¿£Áø.EXE
4: create ( ) gFile : GrpFile
Alpha
Diagram
8: fillFile ( ) UNIX
ÀÀ¿ë¼­¹ö.EXE
Windows
NT
user : »ç¿ëÀÚ GraphicFile
User Interface
IBM
fileMgr : FileMgr File
Mainframe
3: create ( )
FileList
6: fillDocument ( )
Definition
µ¥ÀÌŸº£À̽º¼­¹ö
7: readFile ( )
5: readDoc ( )
document : Document
repository : Repository
Forward Engineering(Code Generation)
Collaboration Diagram Component and
Diagram Reverse Engineering
mainWnd fileMgr : document : gFile repository
user FileMgr Document
Source Code edit, compile, debug, link
ƯÁ¤¹®¼ ´ëÇÑ º¸±â¸¦
­¿¡ 1: D view request ( )
oc
»ç¿ëÀÚ°¡ ¿äûÇÑ´Ù.
2: fetchDoc( )
3: create ( )
4: creat e ( )
5: readDoc ( )
È­ÀÏ°ü¸®ÀÚ´Â ÀÐ ¾î¿Â 6: fillDocument ( )
¹®¼­ÀÇ Á¤º¸¸¦ ÇØ´ç ¹®¼­
°´Ã¼¿¡ ¼³Á¤À» ¿äûÇÑ´Ù.
7: readFile ( )
8: fillFile ( )
È­¸é °´Ã¼´Â ÀоîµéÀÎ 9: sortByName ( )
° ´Ã¼µ ´ëÇØ À̸§º°·Î
é¿¡
Á¤·ÄÀ» ½ÃÄÑ È­¸é¿¡
º¸¿©ÁØ´Ù.
Sequence Diagram
Executable System
37

38. Benefits of a Use-Case Driven Process
Use cases are concise, simple, and understandable by a
wide range of stakeholders
 End users, developers and acquirers understand functional
requirements of the system
Use cases drive numerous activities in the process:
 Creation and validation of the design model
 Definition of test cases and procedures of the test model
 Planning of iterations
 Creation of user documentation
 System deployment
Use cases help synchronize the content of different
models
38

39. Summary: Unified Process
The Unified Modeling Language (UML) is a language for
specifying, visualizing, constructing, and documenting
the artifacts of a software-intensive system
A software development process defines Who is doing
What, When and How in building a software product
The Rational Unified Process has four phases: Inception,
Elaboration, Construction and Transition
Each phase ends at a major milestone and contains one
or more iterations
An iteration is a distinct sequence of activities with an
established plan and evaluation criteria, resulting in an
executable release
Rational Unified Process is a commercial version of 39