1 of 41

Software Engineering Concepts (CSC 291)

​

​

Dr. Assad Abbas

​

Associate Professor

Department of Computer Science

COMSATS University Islamabad, Islamabad Campus

assadabbas@comsats.edu.pk

​

2 of 41

Software Process

  • Fundamental Assumption:
    • Good processes lead to good software
    • Good processes reduce risk
    • Good processes enable teamwork
  • Varity of software processes
    • Software products are very varied. Therefore, there is no standard process for all software engineering projects
    • BUT successful software development projects always need to address similar issues. This creates a number of process steps that should be part of all software projects.

2

August 23, 2024

3 of 41

The software process (Simplified)

Operation and Maintenance

​

Requirements

Design Implementation

Feasibility and

Planning

4 of 41

Basic Software Process Steps

  • Feasibility and Planning
  • Requirements
  • System and Program design
  • Implementation
  • Acceptance and Release
  • Operation and Maintenance

These steps may be repeated many times during the development cycle.

4

August 23, 2024

5 of 41

Process Step: Feasibility and Planning

A feasibility study precedes the decision to begin a project.

What is the scope of the proposed project?

Is the project technically feasible?

What are the projected benefits?

What are the costs?

Are the resources available?

What are the risks and how can they be managed?

A feasibility study leads to a decision: go or no-‐go.

6 of 41

Process Step: Requirement

Requirements define the function of the system from the client's viewpoint.

The requirements establish the system's functionality, constraints, and goals by consultation with the client, customers, and users.

They must be developed in a manner that is understandable by both the client and the development staff.

7 of 41

Process Step: Requirement

    • Requirements analysis
    • Requirements definition
    • Requirements specification

This step is occasionally divided into:

The requirements may be developed in a limited manner or may emerge incrementally.

Failure to agree on the requirements and define them adequately is one of the biggest cause of software projects failing.

8 of 41

Process Step: System Design

Design describes the system from the software developers' viewpoint

    • Establish a system architecture, both hardware and software, that matches the requirements

System design:

    • Represent the software functions in a form that can be transformed into one or more executable programs

Program design:

Models are used to represent the requirements, system architecture, and program design.

9 of 41

Process Step: Implementation

    • The software design is realized as a set of programs or program units.
    • These software components may be written by the development team, acquired from elsewhere, or modified from existing components.

Implementation (coding)

    • Program testing by the development staff is an integral part of implementation.
    • Individual components are tested against the design.
    • The components are integrated and tested against the design as a complete system.

Program testing

10 of 41

Process Step: Operation and Maintenance

    • The system is put into practical use.

Operation:

    • Errors and problems are identified and fixed.

Maintenance:

    • The system evolves over time as requirements change, to add new functions, or adapt to a changing technical environment.

Evolution:

    • The system is withdrawn from service.

Phase out:

This is called the Software Life Cycle

11 of 41

Sequence of Process Steps

Sequential:

As far as possible, complete each process step before beginning the next. Waterfall model.

Iterative:

Go quickly through all process steps to create a rough system, then repeat them to improve the system. Iterative refinement.

Incremental:

A variant of iterative refinement in which small increments of software are placed in production (sprints). Agile development.

We will look at three categories of software development processes:

12 of 41

Heavy Weight and Light Weight Software Development

    • Example: Waterfall Model

In a heavyweight process, the development team works through the process steps slowly and systematically, with the aim of fully completing each process step and deliverables for that step that will need minimal changes and revision.

    • Example: Agile Software Development

In a lightweight process, the development team releases working software in small increments, and develops the plans incrementally, based on experience. Each increment includes all the process steps. There is an expectation that changes will be made based on experience.

13 of 41

Deliverables

A deliverable is some work product that is delivered to the client.

In a heavyweight process each process step creates a deliverable, usually documentation, e.g., a requirements specification.

In a lightweight process, the deliverables are incremental working code, with minimal supporting documentation.

14 of 41

Quality Control Steps in all Software Development

Some of these steps will be repeated many times during the life of the system

Validating the requirements

Validating the system and program design

Usability testing

Program testing

Acceptance testing

15 of 41

Software Process Models

15

August 23, 2024

16 of 41

Process Models

    • The Waterfall Model
    • Incremental Process Models
    • Evolutionary Process Models
      • Prototyping
      • The Spiral Model
    • Concurrent Models
      • V-Model (V-Software Development Process Model)

16

August 23, 2024

17 of 41

The Water Fall Model

18 of 41

The Water Fall Model

  • Requirements – defines needed information, function, behavior, performance and interfaces.
  • Design – data structures, software architecture, interface representations, algorithmic details.
  • Implementation – source code, database, user documentation, testing.
  • Test – check if all code modules work together and if the system as a whole behaves as per the specifications.
  • Installation – deployment of system, user-training.
  • Maintenance – bug fixes, added functionality (an on-going process).

18

August 23, 2024

19 of 41

The Water Fall Model

Advantages

  • Easy to understand, easy to use
  • Provides structure to inexperienced staff
  • Milestones are well understood
  • Sets requirements stability
  • Good for management control (plan, staff, track)

Disadvantages

  • All requirements must be known upfront
  • Difficult for the customer to state all requirements explicitly
  • Integration is one big bang at the end
  • Little opportunity for customer to preview the system (until it may be too late)

20 of 41

When to use Water Fall Model

  • Requirements are very well known
  • When it is possible to produce a stable design
    • E.g. a new version of an existing product
    • E.g. porting an existing product to a new platform.

20

August 23, 2024

21 of 41

V-Model

  • Verification and Validation Model
  • Extension of the waterfall model 
  • Based on the association of a testing phase for each corresponding development stage

21

August 23, 2024

22 of 41

When to Use the V-Model

  1. Suitable when project requirements are well-defined and stable.
  2. Effective for small to medium-sized projects with relatively stable requirements.
  3. Commonly used in the development of critical systems and safety-critical applications.
  4. Aligns well with organizations following a waterfall-like development approach.
  5. Advantages in projects where there is a strong emphasis on testing and quality assurance.
  6. Clients or stakeholders may request the V-Model, especially for regulatory compliance.
  7. Appropriate when the risk of requirement changes during development is low.

​

  • Remember: Assess project characteristics, requirement stability, and team expertise when deciding to use the V-Model.

22

August 23, 2024

23 of 41

Incremental Process Model

23

August 23, 2024

24 of 41

Incremental Process Model

Combines elements of the waterfall model applied in an iterative fashion.

Incremental applies linear sequences as the calendar time progress.

Limited software functionalities and expands functionalities in later software release.

25 of 41

Increment Model

Each linear sequence produces a deliverable increment of the software

    • Eg. Word processing software

First increment is often a core product

Basic requirements are addressed, but many supplementary remains undelivered.

Customers evaluate this core product, and the next increment is planned based on suggestions and next set of features

The plan addresses the modification of core product and delivery of additional features and functionalities.

Process is repeated until complete product is produced.

26 of 41

Increment Model

  • Useful when
    • Staff is unavailable for complete implementation and deadline is tight
    • If core product is well received, additional staff can implement next increment
    • Increment can be planned to manage technical risks
    • Partial functionalities can be delivered to end – user without inordinate delay.

​

26

August 23, 2024

27 of 41

Incremental Model

Advantages

  • Generates working software quickly and early during the software life cycle.
  • It is easier to test and debug during a smaller iteration.
  • Customer can respond to each built.
  • Lowers initial delivery cost.
  • Easier to manage risk because risky pieces are identified and handled during iteration.

​

Disadvantages

  • Needs good planning and design.
  • Needs a clear and complete definition of the whole system before it can be broken down and built incrementally.
  • Total cost is higher than waterfall.

​

28 of 41

Evolutionary Process Model

  • These models are more suited to object-oriented systems.
  • They are iterative.
  • They enable the software developer to develop increasingly more complex versions of the software
  • Like all complex systems, software evolves over a period of time and hence evolutionary models are more suited to software development.
  • Requirements change while software gets developed.

28

August 23, 2024

29 of 41

Prototype Model

  • Customer defines objective to software engineer, but not specifies input , process ,output requirements.
  • Developer may be unsure about efficiency of algorithm, adaptability of OS, or human-machine interaction
  • In this situation Prototype is best approach

29

August 23, 2024

30 of 41

Prototype Model

  • Used as standalone Process model
  • Used as a technique implemented in any process model
  • Prototype paradigm assists software and customer to better understand and build the software when requirement is fuzzy

​

30

August 23, 2024

31 of 41

Prototype Model

31

August 23, 2024

32 of 41

Prototype Model

Communication:

    • Software Engineer and customer defines overall objective
    • Identifies requirements and outline area
    • Definition is mandatory

Quick plan is made

Quick design:

    • Focuses on a representation of those aspects of the software that will be visible to end users (e.g., human interface layout or output display formats)

Leads the construction of prototype

Deployed and evaluated

    • by stakeholders, who provide feedback that is used to further refine requirements.

33 of 41

Prototype Model

  • Limitations
    • Prototype is quick and dirty solution
    • At the prototype level no focus on software quality or long-term maintainability
    • Too much changes can disturb rhythm of developer
    • It is a thrown away prototype when the users are confused with it

​

33

August 23, 2024

34 of 41

Spiral Model

Proposed by Barry Boehm - Evolutionary software process model

Couples Iterative nature of prototyping + waterfall model

Potential for rapid development of increasingly more complete version of software

Spiral Model - software is developed in a series of evolutionary releases.

Early iteration - Paper model / prototype (trial product)

Later increasingly more complete version of engineering software is produced

35 of 41

Spiral Model

35

August 23, 2024

36 of 41

Spiral Model

36

August 23, 2024

37 of 41

Spiral Model

    • Specific objectives for the phase are identified.
    • Constraints on the process and the product are identified and a detailed management plan is drawn up
    • Project risks are identified

Objective setting

    • Risks are assessed and activities put in place to reduce the key risks.
    • For example, if there is a risk that the requirements are inappropriate, a prototype system may be developed

Risk assessment and reduction

Each loop in the spiral is split into four sectors

38 of 41

Spiral Model

    • A development model for the system is chosen which can be any of the generic models.
    • For example, throwaway prototyping may be the best development approach if user interface risks are dominant.
    • If safety risks are the main consideration, development based on formal transformations may be the most appropriate process.
    • If the main identified risk is sub-system integration, the waterfall model may be the best development model to use

Development and validation

    • The project is reviewed, and the next phase of the spiral is planned.

Planning

39 of 41

Spiral Model

Advantage:

  • Realistic approach of development in large scale
  • Developer and customer satisfaction
  • Reacts to risk at evolutionary level
  • Uses prototype - Risk reduction mechanism
  • Enables developer to apply prototype in any stage
  • Direct consideration of technical risk at all step.

Disadvantage

  • Can be a costly model to use.
  • Risk analysis requires highly specific expertise.
  • Project’s success is highly dependent on the risk analysis phase.
  • Doesn’t work well for smaller projects.

​

40 of 41

When to use Spiral Model

When costs and risk evaluation is important

For medium to high-risk projects

Long-term project commitment unwise because of potential changes to economic priorities

Users are unsure of their needs

Requirements are complex

Significant changes are expected (research and exploration)

41 of 41

Sources

  • Software Engineering: A Practitioner’s Approach, Roger S. Pressman & Bruce R. Maxim, McGraw-Hill, 2020.

​

41

August 23, 2024