The Software Process

Software Life Cycle

Requirement analysis and definition System and software requirements Implementation and unit testing Integration and system testing Operation and Maintenance

Software Process
A set of activities and associated results which produce a software product. Activities include:
Software specification Software development Software validation Software evolution

Software Engineering is a Layered Technology

Tools Methods Processes Quality Focus

4

Process, Methods, and Tools

Process
Provides the glue that holds the layers together; enables rational and timely development; provides a framework for effective delivery of technology; forms the basis for management; provides the context for technical methods, work products, milestones, quality measures, and change management

Methods
Provide the technical "how to" for building software; rely on a set of basic principles; encompass a broad array of tasks; include modeling activities

Tools
Provide automated or semi-automated support for the process and methods (i.e., CASE tools)

Umbrella Activities
Software requirements management Software project planning Software project tracking and oversight Software quality assurance Software configuration management Formal technical reviews Risk management Measurement process, project, product Reusability management (component reuse) Work product preparation and production
6

What is a Process?
(Webster) A system of operations in producing something; a series of actions, changes, or functions that achieve an end or a result (IEEE) A sequence of steps performed for a given purpose

What is a Software Process?

(SEI) A set of activities, methods, practices, and transformations that people use to develop and maintain software and the associated products (e.g., project plans, design documents, code, test cases, and user manuals) As an organization matures, the software process becomes better defined and more consistently implemented throughout the organization Software process maturity is the extent to which a specific process is explicitly defined, managed, measured, controlled, and effective

Generic Process Framework

Communication
Involves communication among the customer and other stake holders; encompasses requirements gathering

Planning
Establishes a plan for software engineering work; addresses technical tasks, resources, work products, and work schedule

Modeling (Analyze, Design)

Encompasses the creation of models to better understand the requirements and the design

Construction (Code, Test)

Combines code generation and testing to uncover errors

Deployment
Involves delivery of software to the customer for evaluation and feedback

Modeling: Software Requirements Analysis

Helps software engineers to better understand the problem they will work to solve Encompasses the set of tasks that lead to an understanding of what the business impact of the software will be, what the customer wants, and how end-users will interact with the software Uses a combination of text and diagrams to depict requirements for data, function, and behavior
Provides a relatively easy way to understand and review requirements for correctness, completeness and consistency

10 10

Modeling: Software Design

Brings together customer requirements, business needs, and technical considerations to form the blueprint for a product Creates a model that that provides detail about software data structures, software architecture, interfaces, and components that are necessary to implement the system Architectural design
Represents the structure of data and program components that are required to build the software Considers the architectural style, the structure and properties of components that constitute the system, and interrelationships that occur among all architectural components

User Interface Design

Creates an effective communication medium between a human and a computer Identifies interface objects and actions and then creates a screen layout that forms the basis for a user interface prototype

Component-level Design
Defines the data structures, algorithms, interface characteristics, and communication mechanisms allocated to each software component
11 11

Software Process Model

A simplified description of a software process which is presented from a particular perspective. Process Model includes:
Activities of the software process Software products Role of people

12

Process Model Types

Prescriptive
Model includes a specific set of tasks, along with a workflow for these tasks and definite milestones and outcomes for each task; end result is the desired product

"Agile
Model tends to be simpler than prescriptive models; emphasis is on incremental development, customer satisfaction, and minimal process overhead

"Mathematical
Formal Method Model stresses mathematical rigor and formal proofs that product is meeting carefullydefined goals

13

Prescriptive Process Models

Also called conventional process models Have a specific set of:
framework activities Software engineering tasks Work products QA Change control mechanism

14

The Waterfall Model

Proposed in 1970 by Royce Sequential Process Model Its name due to the cascading effect from one phase to the other Move to next phase when its preceding phase is completed and perfected No overlapping in the phases No jumping back and forth in the phases
15

The Waterfall Model (contd)

16

The Waterfall Model (contd)

Documentation Driven Model Applicable when
The requirements are stable and well defined Well defined enhancements to an existing system are to be made

17

The Waterfall Model (contd)

Advantages
Testing is inherent to every phase It is an enforced disciplined approach Maintenance is easier

Disadvantages
Not realistic approach Complete system delivered at the end Difficult to finalize requirements at early stage Difficult cost and time estimations
18

Incremental Process Models

Produce the software in increments Each increment delivers the customer a working product Iterative nature First increment-core product Evaluated by customer Feedback Next increment plan
19

Incremental Process Models (contd)

Advantages
Helps when the project team is small Feedback improves next increment In time working product delivered to customer

Example:
Incremental model RAD (Rapid Application Development)
20

RAD
Incremental software process model Emphasizes short development cycle Faster development Use of Computer Assisted Software Engineering (CASE) Tools Component based construction System delivered in short time (2 to 3 months) Useful where requirements are well understood and scope is limited
21

RAD (contd)
Essential Aspects of RAD:
Methodology
Methods to be used in this model

People
Type of project team required

Management
Managements commitment in providing faster and timely increment

Tools
Computerized tools
22

RAD (contd)
Difficult to manage for large projects Commitment of customer and the development team System cannot be modularized High technical risks

23

Incremental Model (Diagram)

Increment #1
Communicatio n
Plannin g Modeling Constructio n Deployment

Increment #2
Communicatio n Plannin g

Modeling

Constructio n

Deployment

Increment #3
Communicatio n
Plannin g Modeling

Constructio n

Deployment

24 24

Incremental Model (Description)

Used when requirements are well understood Multiple independent deliveries are identified Work flow is in a linear (i.e., sequential) fashion within an increment and is staggered between increments Iterative in nature; focuses on an operational product with each increment Provides a needed set of functionality sooner while delivering optional components later Useful also when staffing is too short for a full-scale development

25 25

Evolutionary Process Models

They are also prescriptive process models Iterative in nature Based on the idea of
Developing an initial implementation Exposing it to user comment Refining

Concurrent activities with feedback

26

Evolutionary Process Models (contd)

Specification Initial Version

Outline Description

Development

Intermediate Version

Validation

Final Version

27

Evolutionary Process Models (contd)

Types
Exploratory Development
Objective is to work with the customer to explore the requirements and deliver a final system.

Throw-away Prototyping
Objective is to understand the customers requirements and develop better requirements definition.

28

Evolutionary Process Models (contd)

Examples:
Prototyping Spiral Model Concurrent Development Model

29

Prototyping
When only general objectives are known Development issues are unknown Often used as a technique within other process models Better understand what is to be built when requirements are fuzzy

30

Prototyping (contd)
Communication

Deployment Delivery & Feedback

Quick Plan

Modeling Quick Design Construction of Prototype

31

Prototyping (contd)
Issues
Customer considers the prototype a working system Less than ideal choice becomes an integral part of the system

32

Spiral Model
Proposed by Boehm (1988) Process is represented as a spiral Each loop in the spiral represents a phase of the software process In early iterations the release might be a paper model or prototype

33

Spiral Model (contd)

34

Spiral Model (contd)

An important aspect is the risk analysis preceding each phase
Risk- something which can go wrong

If risk cannot be solved the project is terminated immediately Issues

Risk assessment needs expertise Uncovered risks can result in later issues

35

Concurrent Development Model

Also called Concurrent Engineering Tasks are done in parallel Each task or activity has its own state. States can be:
None Under development Under review Done Awaiting changes Under revision Under review baselined
36

Concurrent Development Model (contd)

All activities exist concurrently but reside in different states It defines a network of activities rather than a sequence of events Applicable to all types of software development

37

Conclusion
Evolutionary process models focus on changing needs and customer satisfaction Certain issues are:
Project planning concerns in prototyping Speed of evolution? Balance between flexibility, extensibility, speed of development and quality

38

Difference between Evolutionary Models and Incremental Models

Evolutionary Models:
All activities are in iterative fashion

Incremental Models:
Requirements are established initially development activities are iterative.

39

Component Based Development

A software component is a system element offering a predefined service. Component-Based Development is a branch of the software engineering discipline, with emphasis on decomposition of the engineered systems into functional or logical components with well-defined interfaces used for communication across the components.

40

CBD (contd)
Software applications are assembled from components from a variety of sources; the components themselves may be written in several different programming languages and run on several different platforms. COTS
Commercial off-the-shelf software components developed by vendors who offer them as products.
41

CBD (contd)
Modeling
Identification of components.

Available components are researched and evaluated for the domain. Component integration issues. Software architecture is designed. Components are integrated into architecture. Comprehensive testing.
42

CBD (contd)
Conclusion
Software reusability 70% reduction is software cycle 84% reduction in software cost Increased productivity

43

Formal Methods Model

Mathematically based techniques for representing and analysis of software. Formal methods include
Formal specification Specification analysis and proof Transformational development Program verification

Hoare and Dijkstra

44

Formal Methods Model

Reduces requirements errors as it forces a detailed analysis of the requirements Incompleteness and inconsistencies can be discovered and resolved Currently very time consuming and expensive Extensive training required Difficult to use this model to communicate with the customer.

45

Aspect Oriented Software Development

Object-oriented programming (OOP) has become the mainstream programming paradigm where real world problems are decomposed into objects that abstract behavior and data in a single unit.
46

AOSD (contd)
OOP encourages software re-use. Although OOP has met great success in modeling and implementing complex software systems, it has its problems.

47

AOSD (contd)
Practical experience with large projects has shown that programmers may face some problems with maintaining their code because it becomes increasingly difficult to cleanly separate concerns into modules.

48

AOSD (contd)
Aspect Oriented Programming (AOP) is a promising new technology for separating concerns specifically crosscutting concerns that are usually hard to do in object-oriented programming.

49

AOSD (contd)
What is a concern? A concern is any piece of interest or focus in a program. separation of concerns (SoC) is the process of breaking a computer program into distinct features that overlap in functionality as little as possible.
50

AOSD (contd)
Cross-cutting concerns are those parts of program that affect other concerns. Example:
Logging-logging affects all parts of the system that are being logged. Logging thereby crosscuts all logged classes and methods.
51

AOSD (contd)
AOP is a new technology for separating crosscutting concerns into single units called aspects. An aspect is a modular unit of crosscutting implementation. It encapsulates behaviors that affect multiple classes into reusable modules.

52

AOSD (contd)
A distinct aspect-oriented process has not yet matured. May adopt characteristics of both spiral(evolutionary nature) and concurrent (parallel nature) process models.

53

Unified Process
Came during the evolution period of Object Oriented software development methods (1990s) Contains features of OOA and OOD. UML- Unified Modeling Language
It was created to support the OO design and modeling.

54

UP (contd)
Unified Process is an iterative and incremental software development process framework. Not only a process but an extensible framework that can be customized for specific organizations and projects.

55

UP (contd)
Phases:
Inception Elaboration Construction Transition Production

56

UP (contd)
Inception
Customer communication Planning
Identify resources, assess risks, defines schedule

Business requirements are identified

In the form of use cases.

Rough architecture
A tentative outline of major sub-systems, functions and features that populate them.

57

UP (contd)
Elaboration
Customer communication Modeling activity Expands the use cases. Expands the architecture to:
Use case model, analysis model, design model, implementation model and deployment model.

Review plan and make modifications

Evaluate scope, risks, project delivery dates

58

UP (contd)
Construction
Develop software components (that make the use cases operational). Complete the analysis and design models. Implement all functions and features for that increment. Conduct unit testing for the components Integrate components.
59

UP (contd)
Transition
Create user manuals, guidelines, installation procedures. Software is given to users for beta testing. Get user feedback The increment is now a useable software release.

60

UP (contd)
Production
On going use of the software is monitored. Provide support Defect reports and request for changes are submitted and evaluated.

61

UP (contd)
Phases do not occur in a sequence but are concurrent. One increment is in production and work on next increment is already started.

62

UP (contd)
Conclusion
Recognizes the importance of customer communication. Emphasizes architecture. Iterative and incremental process flow.

63