Software Process and Model by Md. Hasan Imam Bijoy
1.
2. Md. Hasan Imam Bijoy
ID: 182-15-11743
Section: E
Department of CSE
Daffodil International University
Presenter
3. Agenda
1 Software Process
2 Software Process Model
3 A Generic Process Model
4 Waterfall Model
5 Incremental Model
6 Reusable Software
SWE ID: 182-15-11743 E
4. Software Process
A software process model is an abstract representation of a process. It presents
a description of a process from some particular perspective.
A structured set of activities required to develop a software system
Many different software processes but all involve:
• Specification – defining what the system should do;
• Design and implementation – defining the organization of the system
and implementing the system;
• Validation – checking that it does what the customer wants;
• Evolution – changing the system in response to changing customer needs.
SWE ID: 182-15-11743 E
5. Software Process Model
A Process Model describes the sequence of phases
for the entire lifetime of a product. Therefore it is
sometimes also called Product Life Cycle.
This covers everything from the initial commercial
idea until the final de-installation or disassembling
of the product after its use.
SWE ID: 182-15-11743 E
6. A Generic Process Model
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.
SWE ID: 182-15-11743 E
8. Waterfall Process Model
The waterfall model this takes the fundamental process activities of
specification, development, validation, and evolution and
represents them as separate process phases such as requirements
specification, software design, implementation, testing, and so on.
There are separate identified phases in the waterfall model:
• Requirements analysis and definition
• System and software design
• Implementation and unit testing
• Integration and system testing
• Operation and maintenance
SWE ID: 182-15-11743 E
9. Waterfall Process Model
SWE ID: 182-15-11743 E
• Requirement Documentary
• Prepare Use Cases
• Software Architecture
• Map the Stockholder
• Construct The Software
• Data Storage & retrieval
• Install
• Test & Debug
• Check Error
• Optimizing Capabilities
10. Leakages of Waterfall
SWE ID: 182-15-11743 E
Inflexible partitioning of the project into distinct stages makes it
difficult to respond to changing customer requirements.
Therefore, this model is only appropriate when the requirements
are well-understood and changes will be fairly limited during the
design process.
Few business systems have stable requirements.
The waterfall model is mostly used for small systems engineering
projects where a system is developed at several sites.
11. Incremental Process Model
SWE ID: 182-15-11743 E
The incremental model combines element
of waterfall model applied in an iterative
fashion.
The incremental model applies linear
sequence like as calendar time progresses.
Each linear sequence.
13. Leakages of Incremental
The process is not visible.
Managers need regular deliverables to measure progress. If systems are
developed quickly, it is not cost effective to produce documents that
reflect every version of the system.
System structure tends to degrade as new increments are
added.
Unless time and money is spent on refactoring to improve the software,
regular change tends to corrupt its structure. Incorporating further
software changes becomes increasingly difficult and costly.
SWE ID: 182-15-11743 E
14. Reusable Software
SWE ID: 182-15-11743 E
Reusable software components are designed to apply the power
and benefit of reusable, interchangeable parts from other
industries to the field of software construction. Other industries
have long profited from reusable components. Reusable
electronic components are found on circuit boards.
15. Advantages and Disadvantages
SWE ID: 182-15-11743 E
Reduced costs and risks as less software is
developed from scratch
Faster delivery and deployment of system
But requirements compromises are inevitable so
system may not meet real needs of users
Loss of control over evolution of reused system
elements