It a bout software processes

1. Software Processes
• Software process models
• Process activities
• Coping with change
• Process improvement

2. The software process
 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.
 A software process model is an abstract representation of a process. It
presents a description of a process from some particular perspective.

3. Software life cycle
 Conception
 Feasibility study /domain analysis.
 Requirement Gathering
 Overall design
 Detailed design
 Development (coding, programing)
 Testing (unit , integration, acceptance)
 Deployment /training
 Maintenance and Evolution

4. Software process model
sometimes called (SDLC)
 Is a simplified representation of a software process.
 Includes
 1. The waterfall model(plan-driven)
 2. Incremental development(Agile processes).
 3. Integration and configuration.

5. Waterfall model

6. 1-Waterfall strengths
 Easy to understand ,easy to use.
 Provide structure to inexperienced staff.
 Milestone are well understood.
 Sets requirement stability.
 Good for management control (plan ,staff ,track).

7. Waterfall deficiencies
 All requirement must be known upfront.
 Deliverables created for each phase are considered frozen inhabits flexibility.
 Can give a false impression of progress.
 Does not reflect problem solving nature of software development iterations of
phases.
 Integration is a big bang at the end.
 Little opportunity for customer to preview the system(until it may be late).

8. When to use waterfall model
 Requirements are very well known.
 Product definition is stable.
 Technology is Understood.
 New version of an existing product.

9. 2. Incremental Development
 Construct a partial implementation of a total system.
 Then slowly add increased functionality.
 The incremental model prioritizes requirements of the system and then
implements them in groups
 Each subsequent release of the system adds function to the previous release
until all designed functionality has been implemented.

10. Incremental Model Strengths
 Develop high-risk or major functions first.
 Each release delivers an operational product customer can respond to each
build.
 Uses divide and conquer breakdown of tasks.
 Lowers initial delivery cost.
 Initial product delivery is fast.
 Customer get important functionality early.
 Risk of changing requirements is reduced.

11. Incremental model

12. Incremental model weakness
 Require good planning and design.
 Require early definition of a complete and fully functional system to allow for
the definition of increments.
 Well-defined module interfaces are required (some will be developed long
before others).
 Total cost of the complete system is not lower.

13. When to use incremental model
 Rusk ,funding ,schedule ,program complexity or need for early realization of
benefits.
 Most of the requirements are known up-front but are expected to evolve over
time.
 A need to get basic functionality to the market early.
 On projects which have lengthy development schedule.

14. Integration and configuration(Reuse
oriented software engineering)
 Based on systematic reuse where system are integrated from existing
components or cots (commercial-off-the-shelf)system.
 Process stages
 Component analysis.
 Requirement modification
 System design with reuse.
 Development and integration
Reuse is now the standard approach for building many types of business system.

15. Reuse oriented software engineering

16. Types of software component
 Web services that are developed according to service standards and which are
available for remote invocation.
 Collection of objects that are developed as a package to be integrated with a
component framework such as .NET.
 Stand-alone software systems(COTS) that are configured for use in particular
environment.

17. Process Activities
 Real software processes are interleaved sequences of technical, collaborative,
and managerial activities with the overall goal of specifying, designing,
implementing, and testing a software system.
 The four basic process activities of specification, development, validation,
and evolution are organized differently in different development processes.
 In the waterfall model, they are organized in sequence, whereas in
incremental development they are interleaved.

18. Software Specification
 The process of stablishing what system are required and the constrains on the
system operation and development.
 Requirement engineering process
 Feasibility study.
 Is it technically and financially feasible to build the system?
 Requirement elicitation and analysis.
 What do the system stockholders require or expect from the system?
 Requirement specification
 Define the requirements in details.
 Requirement Validation
 Check the validity of requirements.

19. The Requirements Engineering
Process

20. Software Development(design and
implementation)
 The process of converting the system specification into an executable system.
 Software design
 Design the software structure that realizes the specification.
 Implementation
 Translate this structure into an executable program.
 The activities of design and implementation are closely related and may be
inter-leaved.

21. A general model of the design process

22. Software Validation (Testing)
 Verification and validation (V&V)is intended to show that system conforms to
its specification and meets the requirements of the system customer.
 Involves checking and review processes and system testing.
 System testing involves executing the system with test cases that are derived
from the specification of the real data to be processed by the system.
 Testing the most commonly used V&V activity.

23. Stages of Testing

24. Testing Phases in a plan-driven
software process

25. Software Evolution
 Software is inherently flexible and can change.
 As requirements change through changing business circumstances , the
software that supports the business must also evolve and change.
 Although there has been a demarcation between development and evolution
(maintenance) this is increasingly irrelevant as fewer and fewer systems are
completely new.