The document discusses various specialized software process models, including component-based development, formal methods, aspect-oriented software development, and the unified process. It describes the phases of the unified process: inception, elaboration, construction, transition, and production, emphasizing the importance of planning and communication. Additionally, it outlines the personal software process (PSP) and team software process (TSP), focusing on metrics-based approaches to high-quality software development.

1. Dr. Huma Hayat
Software Process Models (part-
2)

2. Specialized Process Model
Component Based Development
• Commercial off-the-shelf (COTS) software components, developed by vendors
who offer them as products, provide targeted functionality with well-defined
interfaces that enable the component to be integrated into the software that is
to be built.
• The component-based development model incorporates many of the
characteristics of the spiral model.
• It is evolutionary in nature, demanding an iterative approach to the creation of
software. However, the component- based development model comprises
applications from prepackaged software components.

3. • The component-based development model incorporates the following steps
(implemented using an evolutionary approach):
1. Available component-based products are researched and evaluated for the
application domain in question.
2. Component integration issues are considered.
3. A software architecture is designed to accommodate the components.
4. Components are integrated into the architecture.
5. Comprehensive testing is conducted to ensure proper functionality

4. Specialized Process Model
The Formal Methods Model
• The formal methods model encompasses a set of activities that leads to formal
mathematical specification of computer software.
• Formal methods enable you to specify, develop, and verify a computer-based
system by applying a rigorous, mathematical notation.
• When formal methods are used during development, they provide a mechanism
for eliminating many of the problems that are difficult to over- come using other
software engineering paradigms.
• Ambiguity, incompleteness, and inconsistency can be discovered and corrected
more easily—not through ad hoc review, but through the application of
mathematical analysis.

5. Specialized Process Model
Aspect Oriented Software Development
• As modern computer-based systems become more sophisticated (and
complex), certain concerns—customer required properties or areas of
technical interest—span the entire architecture.
• When concerns cut across multiple system functions, features, and informa-
tion, they are often referred to as crosscutting concerns.
• Aspect-oriented software development (AOSD), often referred to as aspect-
oriented programming (AOP) or aspect-oriented component engineering

6. Cont..

7. The Unified Process
• In some ways the Unified Process is an attempt to draw on the best features
and characteristics of traditional software process models, but characterize
them in a way that implements many of the best principles of agile software
development.
• The Unified Process recognizes the importance of customer communication
and streamlined methods for describing the customer’s view of a system (the
use case).
• It suggests a process flow that is iterative and incremental, providing the
evolutionary feel that is essential in modern software development

8. Unified Process
Phases of Unified Process

9. Unified Process
Phases of Unified Process
1.Inception –
•Communication and planning are main.
•Identifies Scope of the project using use-case model allowing managers to
estimate costs and time required.
•Customers requirements are identified and then it becomes easy to make a
plan of the project.
•Project plan, Project goal, risks, use-case model, Project description, are
made.
•Project is checked against the milestone criteria and if it couldn’t pass these

10. Unified Process
Phases of Unified Process
2. Elaboration –
•Planning and modeling are main.
•Detailed evaluation, development plan is carried out and diminish
the risks.
•Revise or redefine use-case model (approx. 80%), business
case, risks.
•Again, checked against milestone criteria and if it couldn’t pass
these criteria then again project can be cancelled or redesigned.

11. 3. Construction –
•Project is developed and completed.
•System or source code is created and then testing is done.
•Coding takes place.
4. Transition –
•Final project is released to public.
•Transit the project from development into production.
•Update project documentation.
•Beta testing is conducted.
•Defects are removed from project based on feedback from public.
5. Production –

12. Personal And Team Process Models
Personal Process Model
• The Personal Software Process (PSP) emphasizes personal measurement of both
the work product that is produced and the resultant quality of the work product.
• PSP represents a disciplined, metrics-based approach to software engineering.
• 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.
• The PSP model defines five framework activities: planning, design, design review,

13. Personal And Team Process Models
Team Software Process
• The goal of TSP is to build a “self-directed” project team that organizes itself
to produce high quality software.
• TSP defines the following framework activities: project launch, high-level
design, implementation, integration and test, and postmortem.
• Like their counterparts in PSP (note that terminology is somewhat different),
these activities enable the team to plan, design, and construct software in a
disciplined manner while at the same time quantitatively measuring the
process and the product. The postmortem sets the stage for process