Software Process Structure

Danish Javed
 THE SOFTWARE PROCESS
• A process is a collection of activities, actions, and tasks that are performed when some
work product is to be created.
• An activity strives to achieve a broad objective (e.g., communication with stakeholders)
and is applied regardless of the application domain, size of the project, complexity of
the effort, or degree of rigor with which software engineering is to be applied.
• An action (e.g., architectural design) encompasses a set of tasks that produce a major
work product (e.g., an architectural model).
• A task focuses on a small, but well-defined objective (e.g., conducting a unit test) that
produces a tangible outcome.
 The Process Framework
• A process framework establishes the foundation for a complete software
engineering process by identifying a small number of framework activities
that are applicable to all software projects, regardless of their size or
complexity.
• In addition, the process framework encompasses a set of umbrella
activities that are applicable across the entire software process.
 Process Framework Activities
A generic process framework for software engineering encompasses five activities:
• 1. Communication: Before any technical work can commence, it is critically
important to communicate and collaborate with the customer (and other
stakeholders).
• 2. Planning: Any complicated journey can be simplified if a map exists. A
software project is a complicated journey, and the planning activity creates a
“map called software project plan” that helps guide the team as it makes the
journey.
 The Process Framework activities
• 3. Modeling: Whether you’re a landscaper, a bridge builder, an aeronautical
engineer, a carpenter, or an architect, you work with models every day. You create
a “sketch” of the thing so that you’ll understand the big picture.
• 4. Construction: What you design must be built. This activity combines code
generation (either manual or automated) and the testing that is required to uncover
errors in the code.
• 5. Deployment: The software (as a complete entity or as a partially completed
increment) is delivered to the customer who evaluates the delivered product and
provides feedback based on the evaluation.
 Umbrella Activities of Software process
Framework(1)
• Software engineering process framework activities are complemented by a number of
umbrella activities.
• 1. Software project tracking and control —allows the software team to assess progress
against the project plan and take any necessary action to maintain the schedule.
• 2. Risk management —assesses risks that may affect the outcome of the project or the
quality of the product.
• 3. Software quality assurance —defines and conducts the activities required to ensure
software quality.
• 4. Technical reviews —assess software engineering work products in an effort to uncover
and remove errors before they are propagated to the next activity.
 Umbrella Activities of Software process
Framework (2)
• 5. Measurement —defines and collects process, project, and product measures that
assist the team in delivering software that meets stakeholders’ needs; can be used in
conjunction with all other framework and umbrella activities.
• 6. Software configuration management —manages the effects of change throughout
the software process.
• 7. Reusability management —defines criteria for work product reuse (including
software components) and establishes mechanisms to achieve reusable components.
• 8. Work product preparation and production —encompass the activities required to
create work products such as models, documents, logs, forms, and lists.
A software process
framework
 Types of Process Flows
1. Linear process flow executes each of the five framework activities in sequence,
beginning with communication and concluding with deployment.
2. Iterative process flow repeats one or more of the activities before proceeding to the
next.
3. Evolutionary process flow executes the activities in a “circular” manner. Each circuit
through the five activities leads to a more complete version of the software.
4. Parallel process flow executes one or more activities in parallel with other activities
(e.g., modeling for one aspect of the software might be executed in parallel with
construction of another aspect of the software).
Linear process flow
Iterative process flow
Evolutionary process flow
Parallel process flow
 Patterns

• An architect named Christopher Alexander first introduced a new

concept of patterns during the late 1970s.
• In software engineering, a software design pattern is a general,
reusable solution to a commonly occurring problem within a given
context in software design.
 What a pattern should be
• Patterns capture nonobvious solutions, not just abstract principles or
strategies, in an indirect manner, as distinct from many other problem-
solving techniques (such as software design paradigms or methods) that
derive solutions from principles.
• Patterns describe relationships between deeper system structures and
mechanisms and not only independent modules.
 Process Pattern
• A process pattern describes a process-related problem that is encountered
during software engineering work, identifies the environment in which the
problem has been encountered, and suggests one or more proven solutions to
the problem
• Process pattern Types:
1. Stage pattern
2. Task pattern
3. Phase pattern
 Process pattern Types(1)
• 1. Stage pattern defines a problem associated with a framework
activity for the process. Since a framework activity encompasses multiple
actions and work tasks, a stage pattern incorporates multiple task patterns
(see the following) that are relevant to the stage (framework activity).
• An example of a stage pattern might be ‘Establishing Communication’.
 Process pattern Types(2)
• 2. Task pattern defines a problem associated with a software engineering
action or work task and relevant to successful software engineering
practice (e.g., Requirements Gathering is a task pattern).
• 3. Phase pattern define the sequence of framework activities that occurs
within the process, even when the overall flow of activities is iterative in
nature. An example of a phase pattern might be Spiral Model or
Prototyping.
 Abstraction
• Abstraction is the act of
representing essential features
without including the background
details or explanations.
 Levels of Abstractions
When you consider a modular solution to any problem, many levels of
abstraction can be posed.
1. At the highest level of abstraction, a solution is stated in broad terms
using the language of the problem environment.
2. At lower levels of abstraction, a more detailed description of the solution
is provided.
 Level of abstractions
• The higher the level, the less detail. The lower level, the more detail. The
highest level of abstraction is the entire system.
Level of abstractions
 Component Abstraction
1. Procedural Abstraction
2. Data Abstraction
 Procedural Abstraction
• A procedural abstraction refers to a sequence of instructions that have a
specific and limited function. The name of a procedural abstraction
implies these functions, but specific details are suppressed.
• An example of a procedural abstraction would be the word ‘open’ for a
door. ‘Open’ implies a long sequence of procedural steps (e.g., walk to
the door, reach out and grasp knob, turn knob and pull door, step away
from moving door, etc.).
 Data Abstraction
• A data abstraction is a named collection of data that describes a data
object. In the context of the procedural abstraction open, we can define a
data abstraction called door. Like any data object, the data abstraction for
door would encompass a set of attributes that describe the door (e.g.,
door type, swing direction, opening mechanism, weight, dimensions).
• It follows that the procedural abstraction open would make use of
information contained in the attributes of the data abstraction door .
 Classification of Patterns
Patterns can be classified in three major categories depending on the level of
abstraction on which they are used when documenting a software solution or design.
1. Architectural Patterns:
• At the highest level of abstraction, architectural patterns deal with the global
properties and architecture of a system composed of large-scale components.
• Architectural patterns capture the overall structure and organization of a software
system, and encode high-level tactics, which describe the set of participating
subsystems, specify their roles, and express the relationships between them.
 Classification of Patterns(II)

2. Design patterns:
• At a lower level of abstraction, design patterns refine the structure and the
behavior of the subsystems as well as the components of a software system, and
the relationships that exist among them. Types of design patterns are structural
patters, creational patterns, behavioral patterns and concurrency patterns
3. Idioms:
• At the lowest level of abstraction, idioms are low-level patterns that are
dependent on the chosen paradigm and the programming language used.