Concurrent Model | Concurrent Engineering

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.

Evolutionary Process Models, stand-alone process model

Evolutionary Process Models, stand-alone process model

Evolutionary models are iterative.
They are characterized develop increasingly more complete versions of the software.

Two common evolutionary process models.
Prototyping.
        The Spiral Model.

Prototyping

Customer defines a set of general objectives for software.

But does not identify detailed requirements for functions and features.

Developer may be unsure of the efficiency of an algorithm.

Prototyping paradigm may offer the best approach.

Can be used as a stand-alone process model.

Better understand what is to be built when requirements are fuzzy.

Start with communication, planned quickly, modeling, Construction, Deployment Delivery & Feedback.

Quick design focuses on GUI that visible to end users.

Quick design leads to the construction of a prototype.

Evaluated by stakeholders, who provide feedback that is used to further refine requirements.

Prototype serves as a mechanism for identifying software requirements.

Problems of prototyping

Stakeholders don’t know what appears to be a working version of the software, Unaware, Compromises in implementation working quickly.

Inappropriate operating system or programming language may be used.
Inefficient algorithm may be implemented.

Incremental Process Models

Incremental Process Models

The incremental model combines of linear and parallel process flows.

the incremental model applies linear sequences deliverable “increments” of the software.

first increment is often a core product. That is, basic requirements

The plan addresses the modification of the core product to better meet the needs of the customer and the delivery of additional features and functionality.

process is repeated until the complete product is produced.

focuses on the delivery of an operational product with each increment.

useful when staffing is unavailable for a complete implementation

core product is well received, then additional staff (if required) can be added to implement the next increment.

increments can be planned to manage technical risks.

The Waterfall Model, classic life cycle

The Waterfall Model, classic life cycle

When work flows from communication through deployment in a reasonably linear fashion.

It may also occur in a limited number of new development efforts, but only when
requirements are well defined and reasonably stable.

The waterfall model, sometimes called the classic life cycle, suggests a systematic,
sequential approach to software development that begins with customer specification
of requirements and progresses through planning, modeling, construction, and
deployment, culminating in ongoing support of the completed software.

Problems of Waterfall Model:

1. Real projects rarely follow the sequential flow that the model proposes.
2. difficult for the customer to state all requirements explicitly.
3. customer must have patience.
4. other members of the team to complete dependent tasks.
5. time spent waiting can exceed the time spent on productive work.

A generic process model, iterative process flow, linear process, evolutionary process,parallel process

A generic process model, iterative process flow, linear process, evolutionary process,parallel process

a process was defined as a collection of work activities, actions, and

tasks that are performed when some work product is to be created. Each of these

activities, actions, and tasks reside within a framework or model that defines their

relationship with the process and with one another.

Each software engineering action is defined by a task set that identifies the work

tasks that are to be completed, the work products that will be produced, the quality

assurance points that will be required, and the milestones that will be used to indicate

progress.

defines five framework activities—communication, planning, modeling,

construction, and deployment.

one important aspect of the software process

This aspect—called process flow—describes how the framework

activities and the actions and tasks that occur within each framework

activity are organized with respect to sequence and time.

• A linear process flow executes each of the five framework activities in sequence, beginning with communication and culminating with deployment.

• An iterative process flow repeats one or more of the activities before proceeding to the next.

• An evolutionary process flow executes the activities in a “circular” manner.

• A parallel process flow executes one or more activities in parallel with other activities.

The Spiral Model

The Spiral Model

• Proposed by Barry Boehm.
• Spiral model is an evolutionary software process model that couples the iterative nature of prototyping with the controlled and systematic aspects of the waterfall model.
• It provides the potential for rapid development of increasingly more complete versions of the software
• A risk-driven process model generator that is used to guide multi-stakeholder concurrent engineering of software intensive systems.
• Two Fetures of spiral model.
• 1.Cyclic
• Incrementally growing a system's degree of definition and implementation while decreasing its degree of risk.
• 2.Anchor Point Milestones
• Assure that stakeholder commitment to feasible and mutually satisfactory system solutions.
• divided into a set of framework activities defined by the software engineering team.
• evolutionary process begins, the software team performs activities that are implied by a circuit around the spiral in a clockwise direction, beginning at the center.
• Risk is considered as each revolution.
• A combination of work products and conditions that are attained along the path of the spiral—are noted for each evolutionary pass.
• Each pass results in adjustments to the project plan.Cost and schedule are adjusted based on feedback derived from the customer.
• The spiral model is a realistic approach to the development of large-scale systems and software.
• The spiral model is not a solution.
• Difficult to convince customers that the evolutionary approach is controllable.
• If a major risk is not uncovered and managed, problems will undoubtedly occur.