CHAPTER 3: GENERIC PROCESS MODELS
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
A generic process framework for
software engineering defines five framework activities—communication, planning,
modeling, construction, and deployment. In addition, a set of umbrella
activities—project tracking and control, risk management, quality assurance,
configuration management, technical reviews, and others—are applied
throughout the process.
Following are the types of Process flows
· A linear process flow executes each of the five framework activities in sequence, beginning with communication and culminating with deployment (Figure 2.2a).
· An iterative process flow repeats one or more of the activities before proceeding to the next (Figure 2.2b).
·
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 (Figure 2.2c).
·
A parallel process flow (Figure 2.2d) 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).
For a small
software project requested by one person (at a remote location) with simple, straightforward
requirements, the communication activity might encompass little more than a
phone call with the appropriate stakeholder. Therefore, the only necessary
action is phone conversation, and the work tasks (the task set) that this
action encompasses are:
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.
PERSONAL AND
TEAM PROCESS MODELS:
Personal
Software Process (PSP):
Personal and team process models refer to methodologies and approaches used by individuals or small teams in the development of software or other projects. These models focus on the processes, strategies, and collaboration methods employed at the individual or small group level.
The Personal
Software Process (PSP) emphasizes personal measurement of both the work product
that is produced and the resultant quality of the work product. In addition PSP
makes the practitioner responsible for project planning (e.g., estimating and
scheduling) and empowers the practitioner to control the quality of all
software work products that are developed.
This activity
isolates requirements and develops both size and resource estimates. In
addition, a defect estimate (the number of defects projected for the work) is
made. All metrics are recorded on worksheets or templates. Finally, development
tasks are identified and a project
schedule is created.
High-level design:
External
specifications for each component to be con[1]structed
are developed and a component design is created. Prototypes are built when
uncertainty exists. All issues are recorded and tracked.
High-level
design review:
Formal
verification methods are applied to
uncover errors in the design. Metrics are maintained for all important tasks
and work results.
Development:
The
component-level design is refined and reviewed. Code is generated, reviewed,
compiled, and tested. Metrics are maintained for all important tasks and work
results.
Postmortem:
Using the measures and metrics collected (this is a substantial amount of data that should be analyzed statistically), the effectiveness of the process is determined. Measures and metrics should provide guidance for modifying the process to improve its effectiveness.
Team Software Process (TSP):
Watts Humphrey extended the
lessons learned from the introduction of PSP and proposed a Team Software
Process (TSP). The goal of TSP is to build a “self-directed” project team that
organizes itself to produce high-quality software.
Humphrey [Hum98] defines the following objectives for TSP:
- Build self-directed teams that plan and track their work, establish goals, and own their processes and plans. These can be pure software teams or integrated product teams (IPTs) of 3 to about 20 engineers.
- Show managers how to coach and motivate their teams and how to help them sustain peak performance.
- Accelerate software process improvement by making CMM23 Level 5 behavior normal and expected.
- Provide improvement guidance to high-maturity organizations.
- Facilitate university teaching of industrial-grade team skills.
A self-directed
team has a consistent understanding of its overall goals and objectives;
defines roles and responsibilities for each team member; tracks quantitative project
data (about productivity and quality). TSP defines the following framework
activities: project launch, high-level design, implementation, integration and
test, and postmortem.
Product
& Process:
Product:
In the context
of software development, a product refers to the end result of the development
process, which could be a software application, system, or any deliverable that
meets the specified requirements. The product is the tangible output that users
or stakeholders can interact with and use to fulfill their needs. It
encompasses both the executable software and any associated documentation, user
manuals, or other deliverables. The quality of the product is determined by how
well it meets the functional and non-functional requirements, its reliability,
performance, and user satisfaction.
Process:
The process in
software development refers to the set of activities, methods, and steps
followed to conceive, design, implement, test, and maintain the software
product. It encompasses the entire software development life cycle, from
initial planning and requirements gathering to coding, testing, deployment, and
maintenance. The process involves the collaboration of individuals, adherence
to methodologies or frameworks, and the use of tools and resources to ensure
that the development activities are organized, controlled, and repeatable. A
well-defined and efficient process is crucial for delivering a high-quality
product within budget and time constraints. Continuous improvement of the
process is often emphasized to enhance productivity and outcomes over time.