CS 551 –Prototyping and Architecture

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.

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

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

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

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

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

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

Map Module Screenshots

Larger View Grid Icons

Wrapper Module for TV Screens

Gantt Charts

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

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.

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.

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.

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

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.

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

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

Open Systems Interconnection Model The Foundation for Distributed Software Systems

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

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

Requirements Findings Approximate Occurrences

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’)

Approximate Occurrences Design Findings Approximate Occurrences

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.

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