This is all about software engineering process models, water fall, prototype,

1. Software Process
1. Software Process Model
2. Process Iteration
3. Software Specifications
4. Software design and implementation
5. Software validation
6. Software evolution
1
Satya Prakash Joshi (012BIM31)
Bipin Thapa (012BIM11)
Harish Chand (012BIM15)
Ganesh Pant (012BIM14)

2. Software Process Models
 Software process model is organizing a structured set of activities to
develop a software systems. [i.e. known as life cycle]
 Specification
 Design and implementation
 Validation
 Evolution
 A software process model is an abstract representation of process. It
presents a description of a process from particular perspective.
2

3. Generic Process Models
 The waterfall model
 Defines specification, development, validation and evolution and represent
separate process phases requirement specifications, software design,
implementation, testing etc…
 Evolutionary development
 Initial system is developed from abstract specifications. Refined with customer
input to produce a system that satisfies the customers needs.
 Component-based software engineering
 The system is assembled from existing components rather then developing them
developing from scratch.
3

4. Waterfall Model
 First published model of the software development process.
 System development method that is linear and sequential.
 Once a phase of development is competed, the development proceeds
to the next phase and never turns back.
4

5. Figure of Waterfall Model5

6. Advantage and Disadvantage
 The advantages of the waterfall model are that documentation is
produced at each phase and that it fits with other engineering process
models.
 Easy to understand and use.
 It’s major problem is it’s inflexible portioning of the project into distinct
stages.
 Difficult to change customers requirement at the middle of the software
development process.
6

7. Conclusion of Waterfall
 The waterfall model should only be used when the requirements are well
understood and unlikely to change radically during system development.
7

8. Evolutionary Development
 Evolutionary development is based on the idea of developing an initial
implementation, exposing this to user comment and refining it through
many version until an adequate system has been developed.
 An Evolutionary approach to software development is often more effective
than the waterfall approach in producing system that meet the immediate
needs of customer.
 The advantage of a software process that is based on an evolutionary
approach is that the specification can be developed incrementally.
8

9. Figure of Evolutionary Development9

10. Type of Evolutionary Development
 Exploratory development :
 Explores the customers requirement and develop the final system for customer.
 Developer will know the parts of system and add new features proposed by the
customer.
 Throwaway prototyping
 Process is to understand the customers requirement and develop.
 Concentrates on experimenting with the customer requirement that are poorly
understood.
10

11. Problems with Evolutionary Approach
 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.
 Systems are often poorly structured
 Continual changes tends to corrupt the software structure. Incorporating
software changes becomes increasingly difficult and costly.
11

12. Component-based software
engineering
 Majority of software projects, there is some software reuse.
 When people working on the project known of the designs or code which is
similar to that required. They look for these, modify them as needed and
incorporated them into their system.
 This information reuse takes place irrespective of the development process
that is used. [increasingly used.]
 Reuse oriented approach relies on a large base of reusable software
components and some integrating framework for these components. [they
claim their own rights i.e. COTS – Commercial off –the shelf systems]
12

13. Figure of CBSE13

14. Advantage of CBSE
 ROSE (Reuse-Oriented Software Engineering) has the obvious
advantages of reduces software development complexity
 Reduce cost and risks.
 Easy to develop and modify.
 Faster delivery of software.
 Easy to maintenance and code reusability.
14

15. Process Iteration
 Iterative development is a way of breaking down the software
development of a large application into smaller chunks.
 In iterative development, feature code is designed, developed and tested
in repeated cycles.
 With each iteration, additional features can be designed, developed and
tested until there is a fully functional software application ready to be
deployed to customers.
 Iterative and incremental development are key practices in Agile
development methodologies.
15

16. Incremental Delivery
 The software specifications, design and implementation are broken down
into a series of increments that are each developed in turn.
 Incremental delivery process will combine the advantages of waterfall,
evolutionary and CBSE.
 In an incremental development process, customer identify the services to
be provided by the system.
 They identify which of the services are most important and which are least
important to them.
16

17. Figure of Incremental Delivery17

18. Advantages of Incremental Delivery
 Customers do not have to wait until the entire system is delivered before
they can gain value from it. The first incremental satisfies their most critical
requirements so they can use the software immediately.
 Customers can use the early increments as prototypes and gain
experiences that information for later system increments.
 There is a lower risk of overall project failure. Although problems may be
encountered in some increments.
 As the highest priority services are delivered first.
18

19. Spiral Development
 Represent the software process as a sequence of activities with some
backtracking one activity to another, the process is represented as a spiral.
 This model is risk oriented and comprises the features of the prototype and
waterfall model.
 This model is used for larger projects, expensive and complicated projects
because of where proper risk assessment is essential.
 Users can see the system earl because of rapid prototyping features. Risk
evaluation may take longer time in the system development process.
19

20. 20

21. Process Activities
 Specifications
 Development
 Validation
 Evolution
21

22. System Requirement Specification (SRS)
22

23. Definitions:
 A software requirements specification (SRS) is a description of a software system to be
developed, laying out functional and non-functional requirements, and may include a set
of use cases that describe interactions the users will have with the software.
 Software specifications, or specs, are documents which define the functionality and
technical details of a software application or system.
 A software requirements specification (SRS) is a comprehensive description of the
intended purpose and environment for software under development.
23

24.  The SRS fully describes what the software will do and how it will be expected to perform.
 A good SRS defines how an application will interact with system hardware, other programs and human users
in a wide variety of real-world situations.
 The basic purpose of SRS is to bridge the communication gap between the parties involved in the
development of the software.
 It provides feedback to the customer.
24

25. Characteristics of SRS
 Correct
 Unambiguous
 Complete
 Consistent
 Ranked Importance
 Verifiable
 Modifiable
 Traceable
25

26. Advantages of SRS
 It establishes the basis of agreement between the client and the supplier on what the software product will
do.
 An SRS minimizes the time and effort required by developers to achieve desired goals and also minimizes
the development cost.
 It provides a reference for validation of the final product.
26

27. System Design
 the process of defining the architecture, components, modules,
interfaces, and data for a system to satisfy specified requirements
 seen as the application of systems theory to product development
 design implies a systematic approach to the design of a system
 the process is systematic wherein it takes into account all related
variables of the system that needs to be created—from the
architecture, to the required hardware and software, right down to
the data and how it travels and transforms throughout its travel
through the system
27

28. Things to be aware of
 What is the system?
 What is the environment?
 What goal does the system have in relation to its environment?
 What is the feedback loop by which the system corrects its actions?
 How does the system measure whether it has achieved its goal?
 Who defines the system, environment, goal, etc.—and monitors it?
 What resources does the system have for maintaining the
relationship it desires?
 Are its resources sufficient to meet its purpose?
28

29. System design steps
 Define project goal and objectives
 Develop the project system requirements
 Identify the major system components that satisfy
the system requirements
 Identify the major system interfaces
 Refine the system design
 Define subsystems making up each component
 Specify interfaces between subsystems
 Establish management controls for the system
interfaces
29

30. Types of design
1) Architectural design:- The architectural design of a system
emphasizes on the design of the systems architecture which
describes the structure, behavior, and more views of that
system and analysis.
2) Logical design:- The logical design of a system pertains to an
abstract representation of the data flows, inputs and outputs
of the system. In the context of systems design are included.
Logical design includes ER Diagrams i.e. Entity Relationship
Diagrams.
30

31. 3) Physical design:- The physical design relates to the actual input and
output processes of the system. This is laid down in terms of how data
is input into a system, how it is verified/authenticated, how it is
processed, and how it is displayed as In Physical design, the following
requirements about the system are decided.
Input requirement,
Output requirements,
Storage requirements,
Processing Requirements,
System control and backup or recovery.
31

32. System Implementation
 This is one of the most vital phase as in this phase the analyst
actually gives the system to the customer and expects for a positive
feedback.
 Is the process of converting the design in a real system through
coding.
 Implementation phase includes coding and testing.
 This Phase will provide users with the documentation and training
required to use the system effectively.
 Data Conversion will only occur once, but user documentation will
be required.
32

33. Coding Phase
 In the coding/development phase the individual objects or
components of the application are coded from the physical model.
 Once the system objects have been developed, they are gathered
and connected together (integrated) to create a working
application.
 The integrated application is placed on a staging server for testing.
 Developers have to follow the coding guidelines defined by their
organization and programming tools like compilers, interpreters,
debuggers etc are used to generate the code
 For E.g. C, C++, Pascal, Java, and PHP are used for coding.
33

34. Testing Phase
 Once the engineer is through with the coding stage he tests the
systems and sees to it that it is working as per the expectations or
not.
 He corrects the flaws in the system if any.
 Testing is becoming more and more important to ensure customer’s
satisfaction, and it requires no knowledge in coding, hardware
configuration or design.
34

35. Testing Types
1) Static Testing :-
 Static testing refers to testing something that’s not running.
 It is examining and reviewing it. i.e., to check whether the work done
meets the standards of the organization.
 Reviews, Inspections and Walk-throughs are static testing
methodologies.
 Example: The specification is a document and not an executing
program. When we read it to find out the issues, it is considered as static
testing.
35

36. 2) Dynamic Testing:-
 Dynamic Testing involves working with the software, giving
input values and checking if the output is as expected.
 These are the Validation activities.
 Unit Tests, Integration Tests, System Tests and Acceptance
Tests are few of the Dynamic Testing methodologies.
Techniques used are determined by type of testing that must be conducted.
 Functional ("black box") testing :- Black box testing involves looking at the
specifications and does not require examining the code of a program. Tests that
examine the observable behavior of software as evidenced by its outputs without
referencing to internal functions is black box testing.
 Structural (usually called "white box") testing:- white box testing requires
programming knowledge to know the internals of the code. Also it is time
consuming. So only a developer can become a white box tester.
36

37. System Documentation
 Software documentation is an important part of software process.
 A well written document provides a great tool and means of
information repository necessary to know about software process.
 Software documentation also provides information about how to
use the product.
37

38. Requirement documentation
 This documentation works as key tool for software designer,
developer and the test team to carry out their respective tasks.
 This document contains all the functional, non-functional and
behavioral description of the intended software.
38

39. Software Design documentation
 These documentations contain all the necessary information, which
are needed to build the software.
 It contains:
(a) High-level software architecture
(b) Software design details
(c) Data flow diagrams
(d) Database design
39

40. Technical documentation
 These documentations are maintained by the developers and
actual coders.
 These documents, as a whole, represent information about the
code.
 While writing the code, the programmers also mention objective of
the code, who wrote it, where will it be required, what it does and
how it does, what other resources the code uses, etc.
40

41. User documentation
 This documentation is different from all the above explained.
 All previous documentations are maintained to provide information
about the software and its development process.
 But user documentation explains how the software product should
work and how it should be used to get the desired results.
41

42. Software Validation
42

43.  Software Validation is the process of checking that a software system meets specifications and
that it fulfills its intended purpose.
 It may also be referred to as software quality control.
 Validation checks that the product design satisfies or fits the intended use (high-level checking),
i.e., the software meets the user requirements. This is done through dynamic testing and other
forms of review.
 It verifies that the software being developed implements all the requirements specified in the SRS
document.
 Software validation is the process of ensuring that your application meets functional and non-
functional requirements before coding and during development.
43

44. Software Evolution
 Generally, software evolution refers to the study and management of the
process of making changes to software over time.
 software evolution comprises:
• Development activities:
Sometimes, software evolution is used to refer to the activity of adding new
functionality to existing software.
• Maintenance activities:
Maintenance refers to the activity of modifying software after it has been put to
use in order to maintain its usefulness.
• Reengineering activities:
Rewriting all or parts of the system to Improve the program structure system
performance
44

45. Importance of Evolution
 Organizations have huge investments in their software systems - they are critical
business assets.
 To maintain the value of these assets to the business, they must be changed and
updated.
 The majority of the software budget in large companies is devoted to evolving
existing software rather than developing new software.
 Saves money and Time
 Accuracy can be maintained
 Flexibility
45

46. 46