Wednesday, November 23, 2016

The Unique Nature of Web Apps

The Unique Nature of Web Apps


Introduction:

In the early days of the World Wide Web (1990 to 1995), websites consisted of little more than a set of linked hypertext files that presented information using text and limited graphics.
Today, WebApps have evolved into sophisticated computing tools that not only provide stand-alone function to the end user, but also have been integrated with corporate databases and business applications due to the development of HTML, JAVA, xml etc.

Attributes of WebApps :

Network Intensiveness
Concurrency
Unpredictable load
Performance
Availability
Data driven
Content Sensitive
Continuous evolution
Immediacy
Security
Aesthetic

Network intensiveness.
A WebApp resides on a network and must serve the needs of a diverse community of clients.
The network may enable worldwide access and communication (i.e., the Internet) or more limited access and communication
(e.g., a corporate Intranet Network Intensiveness)

Concurrency : [ Operation at the same time]
A large number of users may access the WebApp at one time. In many cases, the patterns of usage among end users will vary greatly.

Unpredictable load :
The number of users of the WebApp may vary by orders of magnitude from day to day. One hundred users may show up on Monday; 10,000 may use the system on Thursday.

Performance :
If a WebApp user must wait too long (for access, for server side processing, for client-side formatting and display), he or she may decide to go elsewhere.

Availability :
Although expectation of 100 percent availability is unreasonable, users of popular WebApps often demand access on a 24/7/365 basis.

Data driven :
The primary function of many WebApps is to use hypermedia to present text, graphics, audio, and video content to the end user.
In addition, WebApps are commonly used to access information that exists on databases that are not an integral part of the Web-based environment (e.g., e-commerce or financial applications).

Content sensitive:
The quality and artistic nature of content remains an important
Determinant of the quality of a WebApp.

Continuous evolution:
Unlike conventional application software that evolves over a series of planned, chronologically spaced releases, Web applications evolve continuously.
It is not unusual for some WebApps (specifically, their content) to be updated on a minute-by-minute schedule or for content to be independently computed for each request.

Immediacy:
Although immediacy—the compelling (forceful) need to get software to market quickly—is a characteristic of many application domains,
WebApps often exhibit a time-to-market that can be a matter of a few days or weeks.

Security:
Because WebApps are available via network access, it is difficult, if not impossible, to limit the population of end users who may access the application. In order to protect sensitive content and provide secure mode of data transmission, strong security measures must be implemented.

Aesthetics : [Artistic / Visual]
An undeniable part of the appeal of a WebApp is its look and feel. When an application has been designed to market or sell products or ideas, aesthetic may have as much to do with success as technical design.


Thursday, November 17, 2016

Concurrent Model | Concurrent Engineering

Concurrent Model

Concurrent Model


  • The concurrent development model, sometimes called concurrent engineering.

  • It allows a software team to represent iterative and concurrent elements of any of the process model.

  • For example, the modeling activity defined for the spiral model is accomplished by invoking one or more of the software engineering actions: prototyping, analysis, and design.

  • The activity—modeling—may be in any one of the states noted at any given time.

  • Similarly, other activities, actions, or tasks (e.g., communication or construction) can be represented in an similar manner. 
  •     All software engineering activities exist concurrently but reside in         different states.

  • For example, early in a project the communication activity (not shown in the figure) has completed its first iteration and exists in the awaiting changes state.

  • The modeling activity (which existed in the inactive state while initial communication was completed, now makes a transition into the under development state. If, however, the customer indicates that changes in requirements must be made, the modeling activity moves from the under development state into the awaiting changes state. 
  • Concurrent modeling defines a series of events that will trigger transitions from state to state for each of the software engineering activities, actions, or tasks.