Process model
What is it?
They define a distinct set of activities, actions, tasks, milestones, and work products
that are required to engineer high-quality software
They are not perfect but they provide a useful roadmap for SW engineering work
Who does it?
SW engineers, and their managers adopts it, also the people who requested the software
Why it is important?
They are important because they provide stability, control, and organization to an
activity that can, if left uncontrolled, become quite chaotic
What are the steps?
The process guides a SW team through a set of framework activities that are organized
into a process flow that may be linear, incremental, or evolutionary
What is the work product?
The work products are the programs, documents, and data that are produced as a
consequence of the activities and tasks defined by the process
How do I ensure that I have done it right?
The quality, timeliness, and long term viability of the product you build are the best
indicators of the efficacy of the process that you use
Prescriptive Models
Every SW engineering organization should describe a unique set of framework
activities for the SW process it adopts
Each framework activity is populated with a set of SW engineering actions
Each action is defined in terms of a task set that identifies the work (and work products)
to be accomplished to meet development goals
Resultant process model is adapted to accommodate specific nature of each project,
people who do the work, environment in which work is conducted
SW engineers have traditionally chosen a generic process framework that encompasses
the following framework activities: communication, planning, modeling, construction, and
deployment
All SW process models can accommodate the generic framework activities, but each
applies a different emphasis to these activities and defines a workflow that invokes each
framework activity in a different manner
The Waterfall Model
Used when requirements well understood, when work flows from communication
through deployment in a reasonably linear fashion
Waterfall model, sometimes called classic life cycle, suggests a systematic, sequential
approach to software development that begins with customer specification of requirements and
progresses through various phases, culminating in on-going support of the completed software
Problems with Waterfall Model
Real projects rarely follow the sequential flow that the model proposes
It is often difficult for the customer to state all requirements explicitly
The customer must have patience. A working version of the program will not be
available until late in the project time-span
The Incremental process Models
• They are used when initial requirement are reasonably well-defined but the over all
scope precludes a purely linear process , and need to provide software functionality to user
quickly.
The Incremental Model
It combines elements of the waterfall model applied in an iterative fashion
It delivers a series of releases, called increments, that provide progressively more
functionality for customer as each increment is delivered
When it is used, the first increment is often a core product. That is, basic requirements
are addressed, but many supplementary features remain undelivered
The core product is used by customer. As a result, a plan is developed for next
increment
Unlike prototyping, the incremental model focuses on the delivery of an operational
product with each increment
Incremental development is particularly useful when staffing is unavailable for a
complete implementation by the business deadline. Early increments can be implemented with
fewer people, and additional staff can be added to later increments
Increments can be planned to manage technical risks
The RAD Model
RAD is an incremental SW process model that emphasizes a short development cycle
RAD model is a “high-speed” adaptation of the waterfall model, in which rapid
development is achieved by using a component-based construction approach
If requirements are well understood and project scope is constrained, the RAD process
enables a development team to create a “fully functional system” within a very short time
period
Time constraints imposed on a RAD project demand scalable scope
If a business application can be modularized in a way that enables each major function
to be completed in less than 3 months, it is a candidate for RAD
Each major function can be addressed by a separate RAD team and then integrated to
form a whole
Drawback of RAD
1. For large, but scalable projects, RAD requires sufficient human resources to create right
number of RAD teams
2. If developers and customers are not committed to the rapid-fire activities necessary,
RAD projects will fail
3. If a system cannot be properly modularized, building the components necessary for
RAD will be problematic
4. RAD may not be appropriate when technical risks are high
Evolutionary Process Models
Evolutionary models are iterative. They are characterized in a manner that enables SW
engineers to develop increasingly more complete versions of the software
Evolutionary Models: Prototyping
Although it can be used as a standalone process model, it is more commonly used as a
technique that can be implemented within the context of other process models
The prototyping paradigm assists the SW engineer and the customer to better
understand what is to be built when requirements are fuzzy(customer identify general objective
but not defines the details of input ,processing , and processing so the developer becomes
unsure about efficiency , algorithms and so on to solve this problem prototype is used )
Ideally, the prototype serves as a mechanism for identifying SW requirement
Drawbacks of Prototyping
The customer sees what appears to be a working version of SW, unaware that in the
rush to get it working we haven’t considered overall quality or long-term maintainability
The developer often makes implementation compromises in order to get prototype
working quickly
The Spiral
It is an evolutionary SW process model that couples the iterative nature of prototyping
with the controlled and systematic aspects of the waterfall model
It is a risk-driven process model generator that is used to guide multi-stakeholder
concurrent engineering of SW intensive systems
Using this model software is developed in a series of evolutionary releases. The
releases might be paper model, or prototype.
The model is divided into a set of framework activities defined by SE team
It has distinguishing features: (1) A cyclic approach for incrementally growing the
system’s degree of definition & implementation while decreasing its degree of risk, (2) a set of
anchor point milestones(combination of work product and conditions that are attained along
the path of the spiral)
Unlike other models that ends when software delivered, but it can be adapted to apply
through out the life of software. So the first circle represents "concept development project",
the later represents "new product development" and "product enhancement"
It a realistic model that can be used to be used to develop large scale system and
software
Problems with Spiral Model
Difficult to convince customers that evolutionary approach is controllable
Demands considerable risk assessment expertise and relies on this expertise for success
If major risks are uncovered and managed, problems will occur
Concurrent development model
The concurrent process model defines a series of events that will trigger transition from
state to state for each of the SW engineering activities, actions or tasks. All activities exist
concurrently but reside in different states
E. g. The modeling activity which existed in none state while initial communication
was completed, now makes a transition into under development state. If customer indicates
that changes in requirements must be made, modeling activity moves from under
development state into awaiting changes state
Is applicable to all types of software development and provides an accurate picture of
the current state of project
Each activity, action, or task on the network exists simultaneously with other activities,
actions, or tasks. Events generated at one point in the process network trigger transitions
among the states
Specialized process models
Component based development
—the process to apply when reuse is a development objective
o CBM incorporate the following steps
o Available component product are researched and evaluated for the application
domain in the question
o Component integration issue are considered
o Software architecture is designed to accommodate the component
o Component are integrated with the architecture
o Comprehensive testing is conducted to ensure proper functionality
Formal methods
o It emphasizes the mathematical specification of requirements
o The formal methods model encompasses a set of activities that leads to formal
mathematical specification of computer software.
o Formal methods enable a software engineer to specify, develop, and verify a
computer-based system by applying a rigorous, mathematical notation. A variation on
this approach, called cleanroom software engineering [MIL87, DYE92], is currently
applied by some software development organizations.
o Although it is not destined to become a mainstream approach, the formal
methods model offers the promise of defect-free software. Yet, the following concerns
about its applicability in a business environment have been voiced:
1. The development of formal models is currently quite time consuming and
expensive.
2. Because few software developers have the necessary background to apply
formal methods, extensive training is required.
3. It is difficult to use the models as a communication mechanism for
technically
unsophisticated customers.
Aspect oriented software development
- Often referred to as aspect oriented programming
- Its anew software paradigm that provides methodologies and approaches for defining,
specifying, designing and construct aspect
- Aspect “ mechanism beyond subroutines and inheritance for localizing the expression
of crosscutting concerns[ function, feature, and information content]
- It adopts characteristics of spiral and concurrent process model
- Evolutionary nature of the spiral model is appropriate aspect are identified and then
constructed
- Aspect are engineering independently of localizing software components
Unified process
- it recognizes the importance of customer communication and streamlined methods for
describing the customer view of a system
- it emphasizes the important role of architecture that help to understand the system and
reliance to future changes and reuses
- it suggest a process flow that is iterative or incremental
Phases of Unified Process Modelling
1- inception phase, encompasses both customer communication and planning activities
2- elaboration phase, encompasses customer communication and generic activities of
process model
- It refines use case that were developed as a part of inception phase
3- Construction phase is similar to construction phase in generic process
4- Transition phase, encompasses the latter stage of the generic construction activity and
first part of deployment
5- production, encompasses deployment activity of generic process
o the ongoing use of software is monitored, and reports fro effect and change are
submitted and evaluated
- workflow identifies the tasks required to accomplish an important software engineering
action and work product
- its distributed across all UP phases