1. CS 551 –Prototyping and Architecture

2. Prototyping with Reuse
Application level development
Entire application systems are integrated with the prototype so that their functionality can be shared
For example, if text preparation is required, a standard word processor can be used
Component level development
Components are mutually independent
Individual components are integrated within a standard framework to implement the system
Framework can be a scripting language or an integration platform.
As of 15 Sept.

3. Key points
A prototype can be used to give end-users a concrete impression of the system’s capabilities
Prototyping is becoming increasingly used where rapid development is essential
Throw-away prototyping is used to understand the system requirements
In evolutionary prototyping, the system is developed by evolving an initial version to the final version

4. Key points
Rapid prototyping may require leaving out functionality or relaxing non-functional constraints
Prototyping techniques include the use of very high-level languages, database programming and prototype construction from reusable components
Prototyping is essential for parts of the system such as the user interface which cannot be effectively pre-specified
Users must be involved in prototype evaluation

5. Harbor Radar CS 551 Senior Design
Case History
Harbor Radar
CS 551 Senior Design

6. Project Overview
To primarily serve boaters in the Hudson River area with a 40 mile radius and inexpensive TV to display weather info, buoy data, and plotted locations
Interactive website
Accessible to everyone
Secure section where admin can control information displayed with ability to plot coordinates and alter broadcast information
Difficult time writing requirements and setting scope

7. Requirements Website Design
-Easy to use, clean, intuitive and clearly display maps
Reliability
High reliability requested by customer
Availability
Ultimate goal of 24/7, however probably not doable. 20/7 has been suggested

8. Requirements (cont.) Performance
Website will support 50 simultaneous users
Reach for goal of 100
Television broadcast(s) place little load on the system
Response Time
Average of .5s
Constraints
Television resolution will be an issue
Aim to be readable on a 9” screen
Support both IE and Netscape, versions TBD

9. Map Module Screenshots

10. Larger View
Grid
Icons

11. Wrapper Module for TV Screens

12. Gantt Charts

13. Systems Architecture CS 551 Lecture 4 P E R F O & M A ERROR RECOVERY N
REQUIRE
MENTS
PROBLEM
CS 551 Lecture 4

14. Software Architecture Lessons
A good software architecture may be the single most important characteristic for a successful software development.
It is the key framework for all technical decisions.
It has a profound influence on the organization of the project.
The architecture of the system should be documented in a clear and concise way and communicated to everyone on the project.
Use architecture reviews to make sure that the integrity of the architecture is preserved as new features and functions are added.
Periodically renew the architecture.

15. What is Software Architecture?
The framework for all technical decisions.
A coherent, justified collection of design decisions.
Technology and platform selection to match the problem.
A vehicle for communication among stakeholders.
A balance between features, cost and schedule.
A reusable and transferable abstraction of a system.
The basis for a product line or product family.
A mechanism to insure that the system meets the reliability, capacity, response time and throughput requirements.
Simplest satisfactory solution.

16. Benefits of Good Software Architectures
Helps identify and isolate reusable components that can speed implementation and improve system quality.
Assists in measuring project impacts of inevitable ongoing technical and business decisions and compromises.
Leads to clearly defined organizations with inherent project efficiencies, good communications and decision making.

17. Architecture in a Project’s Life Cycle
It encompasses the requirements, architecture and high level design phases of the
typical waterfall diagram. It also continues throughout the life of the project
(someone continues to wear the architect’s hat).
Planning and
Architecture Phase
Prospectus
Iterative process
until consensus
is reached
Requirements
Carries through the
life of the project
Discovery
Review
Architecture
High
Level
Design
Low
Level
Architecture
Design
Review

18. What we look for in an Architecture
The purpose the system is intended to satisfy.
The major functional components and/or platforms.
The relationship between the components.
The fit to function.
The dynamic interplay of control and communication between these components.
The system’s ease of use.
The data storage and flow of data among these components.
The resources which are consumed by each component in the performance of its task.

19. Kruchten’s “4 + 1”Model for Developing Software Architecture
+ 1 Business
Scenario
View 1
View 2
Process --
System
Integrators
Logical --
End Users
+ 1 Business
Scenario
View 4
View 3
Execution --
Programmers
Physical --
Engineers
This is an innovative and
comprehensive integration
of the abstractions needed to
design the structure for writing
system requirements.
+ 1 Business
Scenario

20. Cost of Modifying Modules for Reuse -- NASA Data for 2954 Modules
Relative
Cost
Amount Modified

21. Open Systems Interconnection Model The Foundation for Distributed Software Systems

22. ARCHITECTURE REVIEWS Found: Problem Areas
Requirements
Performance
ErrRcvy
Other
Tech
Project Management
OA&M

23. Project Management Findings
1. Aggressive schedule forcing inadequate time and focus on fundamental architecture issues
Attempts at working issues in parallel with development often leads to major rework or complete failure
2. Lack of central management or architecture consistency for projects attempting to integrate multiple systems
3. No clear success criteria - multiple, subjective views of customer expectations
4. No clear problem statement - multiple, or conflicting goals
5. No architect (or architecture effort); no central coordination and record of system wide technical decisions
6. Lack of buy-in from all stakeholders on requirements or architecture issues

24. Requirements Findings
Approximate Occurrences

25. Requirements Findings
1. Lack of Functional Requirements
No requirements have been written in key areas
Usage scenarios not understood and documented
Functionality of the system incomplete
Customer unknown or not contacted
No acceptance criteria for the system
2. Lack of Performance & Capacity Requirements
Number and/or types of users undocumented
Transaction and data volumes unknown
Night or batch processing unknown
3. Lack of OA&M Requirements
No OA&M requirements documented
No availability requirements documented
Availability requirements not tied to customer needs (e.g. ‘7 X 24’)

26. Approximate Occurrences
Design Findings
Approximate Occurrences

27. Design Findings 1. Performance Engineering
Often the performance requirements are not fully understood.
“Build it now, tune it later”
Processing, memory, disk utilization (such as database transactions) needs are not well understood by the architects.
Assumption that the system will scale linearly as the load grows
No performance budgets
2. Operations, Administration, Maintenance and Provisioning (OAM&P)
These components include installing the system, booting/rebooting, backup and recovery, remote maintenance and diagnostics, initializing the data needed for the system to operate, and tools to provision the growth of the system.
Design and implementation often underestimated.
Design done late in cycle and inconsistent with remainder of system features.
3. Error Handling and Recovery
Lack of a system error strategy for catching, reporting and recovering from both hardware and software failures.
Error strategy design is the process to examine error scenarios.

28. Acknowledgement
Thanks to Joe Maranzano, he is the class of software architects.