Software Process Frame work:

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 framework activity is populated by a set of software
engineering actions. 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.

A generic process framework for software engineering defines five framework activities—
communication, planning, modeling, construction, and deployment.
The set of umbrella activities—project tracking and control, risk management, quality assurance,
configuration management, technical reviews, and others—are applied throughout the process.

A 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. Each circuit through the five activities leads to a more complete version of the
software. A parallel process flow executes one or more activities in parallel with other activities.

1. Defining a framework activity :

To define a framework activity following questions are to be answered - What actions are
appropriate for a framework activity, given the nature of the problem to be solved, the
characteristics of the people doing the work, and the stakeholders who are sponsoring the project?
 The work task (communication) (the task set) action encompasses are:

1. Make contact with stakeholder

2. Discuss requirements and take notes.
3. Organize notes into a brief written statement of requirements
4. E-mail to stakeholder for review and approval

If the project was considerably more complex with many stakeholders, each with a different set of
(sometime conflicting) requirements, the communication activity might have six distinct actions:

1. inception,
2. elicitation,
3. elaboration,
4. negotiation,
5. specification, and
6. validation.
Each of these software engineering actions would have many work tasks and a number of
distinct work products.

Process Framework Activities:

The process framework is required for representing common process activities. Five framework
activities are described in a process framework for software engineering. Communication, planning,
modeling, construction, and deployment are all examples of framework activities. Each engineering
action defined by a framework activity comprises a list of needed work outputs, project milestones, and
software quality assurance (SQA) points.
 Communication: By communication, customer requirement gathering is done. Comm unication with
consumers and stakeholders to determine the system’s objectives and the software’s requirements.
 Planning: Establish engineering work plan, describes technical risk, lists resources requirements,
work produced and defines work schedule.
 Modeling: Architectural models and design to better understand the problem and for work towards
the best solution. The software model is prepared by:
 1.Analysis of requirements
2. Design
 Construction: Creating code, testing the system, fixing bugs, and confirming that all criteria are met.
The software design is mapped into a code by:
1.Code generation
2.Testing
 Deployment: In this activity, a complete or non-complete product or software is represented to the
customers to evaluate and give feedback. On the basis of their feedback, we modify the product for
the supply of better products.

2. Identifying a Task Set:

Each software engineering action can be represented by a number of different task sets—each a
collection of software engineering work tasks, related work products, quality assurance points,
and project milestones. We should choose a task set that best accommodates the needs of the
project and the characteristics of your team. This implies that a software engineering action can
be adapted to the specific needs of the software project and the characteristics of the project
team.
For example: For a small, relatively simple project, the task set for requirements gathering
might look like this:
1. Make a list of stakeholders for the project.
2. Invite all stakeholders to an informal meeting.
3. Ask each stakeholder to make a list of features and functions required.
4. Discuss requirements and build a final list.
5. Prioritize requirements.
6. Note areas of uncertainty.

For a larger, more complex software project, a different task set would be required. It might
encompass the following work tasks:
1. Make a list of stakeholders for the project.
2. Interview each stakeholder separately to determine overall wants and needs.
3. Build a preliminary list of functions and features based on stakeholder input.
4. Schedule a series of facilitated application specification meetings.
5. Conduct meetings. 6. Produce informal user scenarios as part of each meeting.
7. Refine user scenarios based on stakeholder feedback.
8. Build a revised list of stakeholder requirements.
9. Use quality function deployment techniques to prioritize requirements.
10. Package requirements so that they can be delivered incrementally.
11. Note constraints and restrictions that will be placed on the system.
12. Discuss methods for validating the system

Both of these task sets achieve “requirements gathering,” but they are quite different in their
depth and formality. The software team chooses the task set that will allow it to achieve the
goal of each action and still maintain quality and agility.
 3. Proces Patterns:
A process pattern1 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. Stated in more general terms, a process
pattern provides with a template —a consistent method for describing problem solutions
within the context of the software process. By combining patterns, a software team can solve
problems and construct a process that best meets the needs of a project.
Patterns can be defined at any level of abstraction.2 In some cases, a pattern might be used to
describe a problem (and solution) associated with a complete process model. In other
situations, patterns can be used to describe a problem (and solution) associated with a
framework activity (e.g., planning) or an action within a framework activity (e.g., project
estimating).

Umbrella activities:
Umbrella Activities are that take place during a software development process for improved project
management and tracking.
1. Software project tracking and control: This is an activity in which the team can assess progress
and take corrective action to maintain the schedule. Take action to keep the project on time by
comparing the project’s progress against the plan.
2. Risk management: The risks that may affect project outcomes or quality can be analyzed. Analyze
potential risks that may have an impact on the software product’s quality and outcome.
3. Software quality assurance: These are activities required to maintain software qualit y. Perform
actions to ensure the product’s quality.
4. Formal technical reviews: It is required to assess engineering work products to uncover and
remove errors before they propagate to the next activity. At each level of the process, errors are
evaluated and fixed.
5. Software configuration management: Managing of configuration process when any change in the
software occurs.
6. Work product preparation and production: The activities to create models, documents, logs,
forms, and lists are carried out.
7. Reusability management: It defines criteria for work product reuse. Reusable work items should
be backed up, and reusable software components should be achieved.
8. Measurement: In this activity, the process can be defined and collected. Also, project and product
measures are used to assist the software team in delivering the required software.