Alternative development strategies

1. What is object-oriented modeling?
2. What is RAD?
3. What is synch-and stabilize approach?

Object-oriented concept

1. Object: real-world thing or event
2. Classes: a group of similar objects
3. Messages: communication between objects
4. Encapsulation: an object’s attributes and behaviors are “buffered” from other objects
5. Inheritance: new (derived) classes can be built based in part on old (base) classes
6. Polymorphism: a base class can take the form of any of its derived class depending on circumstance

Object model in VBA

Unified modeling language (Figure 22.26)

Category	Elements	Details
Objects/Things	Structural	Classes Interfaces Collaborations Use cases Active classes Components Nodes
	Behavioral	Interactions States
	Grouping	Packages
	Annotational	Notes
Relationship	Structural	Dependencies Aggregations Associations Generalizations
	Behavioral	Communicates Includes Extends Generalizes
Diagrams	Structural	Class Object Component Deployment
	Behavioral	Use Case Sequence Collaboration State Chart Activity

Use case modeling

Partitions system functionality into behaviors (use cases) from the perspective of the users of the system (actors)

1. Define the use case model

1. Identify users/actors
2. Identify major events and develop primary use cases that describe those events and how the actors initiate them.
3. Establish use case scenarios for each primary use cases.
4. Develop use case diagrams

2. Define the object model

1. Identify objects from the use case model
2. Define the major relationships between objects
3. Develop class diagrams

3. Define the system model

a. Derive the sequence diagrams from use case scenarios and class diagrams

b. Develop state chart, collaboration, and activity diagrams for complex processes that cannot be fully derived by the sequence diagrams

4. Define the system design

a. Derive class specification for each class that include the class properties, methods, and descriptions

b. Develop method specifications for each method

c. Develop deployment diagrams to indicate how your system components will be deployed in the production environment

Comparison of analysis methodologies

Components	Structured	O-O
Entities	ER	Class and object diagram
Relationship	ER	Class and object diagram
Attributes	Data dictionary	Class and object diagram
Decomposition	DFD	N/A
Processing sequence	DFD	N/A
States and transitions	N/A	State-transition diagrams
Entity communications	N/A	Sequence diagram

Comparison of design methodologies

Components	Structured	O-O
Hierarchy of modules	Structured chart	N/A
Procedural logic	Pseudocode	N/A
Inheritance	N/A	Class diagram
Message connections	N/A	Sequence diagram

Source: Fichman, R.G., and Kemerer, C.F., "Object-Oriented and Conventional Analysis and Design Methodologies: Comparison and Critique," IEEE Computer, vol.25, no.10, 1992, pp.22-39

Rapid application development (Figure 8.7)

To rapidly analyze a business problem, to design a visible system solution through intense cooperation between end users and system developers, and to quickly get the finished application in the hands of end users

Advantages and disadvantages of RAD

Advantages	Disadvantages
Time savings Cost savings Meet users' needs Speed of development is a goal Rapid adaptability User involvement Concentrate on essentials User commitment and ownership	Lower overall system quality Out of alignment with the business Inconsistent across systems Violation of standards Discourage module reuse Lack scalability Lack systems administration Escalation

RAD vs SDLC (Figure 8.9)

RAD	SDLC
Respond rapidly to dynamic information requirements	Create systems are complete, accurate, and integrated well with standard business procedures and culture
System design is based on visual model representation of a prototype	System design is based on a conceptual design represented on paper
Users are well involved throughout	Users are separated from analysts after analysis phase

RAD guidelines

1. Well-informed users and developers, e.g., frequent changes in user requirements are expected

2. Supportive organizational climate, e.g., tools are available

3. Need for experimentation

4. Explicit management and control procedure, e.g., set cost, effort, and time limits

Source: Alavi, M., "An Assessment of the Prototyping Approach to Information Systems Development," Communications of the ACM, vol.27, no.6, June, 1984, pp.556-563

Synch-and-stabilize approach

Phase	Description	Deliverables
Planning	Define product vision, specification and schedule	§ Vision statement § Specification document § Schedule and team formation
Development	Divide project into multiple (3 to 4) milestone cycles	§ Fist 1/3 of most critical features and shared components § Next 1/3 of features § Final 1/3 of features
Stabilization	Comprehensive internal and external testing, final debugging, code stabilization, and ship	§ Internal testing § External/beta testing § Release preparation

Synch-and-stabilize vs SDLC

Synch-and-stabilize	SDLC
Product development and testing done in parallel	Separate phases done in sequence
Evolving vision statement and specification	Frozen specification
Features prioritized and built in 3 or 4 milestone subprojects	All pieces of a product are built simultaneously
Frequent synchronization (daily) and intermediate stabilization (milestones)	One integration and system test phase at the end of project
"Fixed" release and ship dates and multiple release cycle	Feature perfection in each cycle
Continuous customer feedback	Feedback after development

Source: Cusumano. M.A., and Selby, R.W., "How Microsoft Builds Software," Communications of the ACM, vol.40, no.6, June, 1997, pp.53-61