Software Development and Professional Practice

Software Development and Professional Practice

L01: The Software Lifecycle

Dr. Nora Shoaip

Damanhour University
Faculty of Computers & Information Sciences
Department of Information Systems

2023

1
Outline

Course Overview
► What is software?
► What is a software process?
► What is a software process model?

2
What is software?

► Software includes computer programs (source code, executable,

byte-code … etc.) and associated documentation such as
requirements document, design document, user manuals … etc.
► New software can be produced from scratch, by configuring
generic software systems, or by reusing existing software

3
What is software?

► Software products may be

► Generic - developed to be sold to a range of different customers
Examples – PC software such as editing, graphics programs, project
management tools; CAD software; software for specific markets such
as appointments systems for dentists.
► custom - developed for a single customer according to their
specification
Examples – embedded control systems, air traffic control
software, traffic monitoring systems.
► Embedded
► Built into hardware
► Hard to change

4
What is software?

► System software: such as compilers, editors, file management

► Application software: stand-alone programs for specific needs.
► Engineering/scientific : software: such as automotive stress analysis,
molecular biology, orbital dynamics etc
► Embedded software : resides within a product or system. (key pad
control of a microwave oven, digital function of dashboard display in a
car)
► Product-line : software focus on a limited marketplace to address
mass consumer market. (word processing, graphics, database
management)
► WebApps : (Web applications) network centric software: remote
database and business applications.
► AI software : Robotics, expert system, pattern recognition game
playing

5
Introduction: Software is Complex

► Complex  complicated
► Complex = composed of many simple parts
related to one another
► Complicated = not well understood, or explained

6
Software Development

Software Development
► refers to a set of computer science activities dedicated to the
process of creating, designing, deploying and supporting software.
► is the science and art of building significant software systems
that are:
1) on time
2) on budget
3) with acceptable performance
4) with correct operation

7
Software Developer vs. Software Engineer.

► Software developers design specific computer systems and

application software. Software engineers work on a larger scale
to design, develop, and test entire computer systems and
application software for a company or organization—software
development is a subset of software engineering.
► A software engineer may work with many different people on a
team, including other engineers and developers. Individuals
working in this role may also work with users to determine
software needs.
► Software developers work with other developers and
programmers on a limited basis. A lot of a developer's work
involves working with applications or operating systems more
than other people.

8
Programmer vs. Software Engineer

Programmer Software Engineer

 Individual with good skills  Part of a team

 Programming-in-the-small  Programming-in-the-large
 Knowledge on data  Knowledge on design
structures, databases, approaches
algorithms.  Translates requirements
 Fluent in one or more into specifications
programming languages  Familiarity in multiple
 May lack formal training application areas
 Minimal exposure to  Converses with users
computer science  Sees the “big picture” of
the software system
 Can model application
 Good communication and
interpersonal skills
9
Software Process and Process Model

► A software process is a set of activities, whose goal is the development

or evolution of a software product
► Four generic activities found in all software processes:
► Specification - what the system should do and the development
constraints imposed on the system
► Development - production of the software system
► Validation - checking that the software is what the customer
wants
► Evolution - changing the software in response to changing
demands
► Software process model is an abstract representation of a software
process, presented from a particular perspective; for example, workflow
(sequence of activities), data-flow, or role/action (who does what)
► Process models explain different approaches to software development

10
Software Process Key Challenges

► Heterogeneity: How to build software that works on different

platforms, that can integrate with older legacy systems which
are written in different programming languages
► Delivery: How to shorten the time it takes to deliver a finished
software product without compromising its quality
► Trust: How to develop techniques to demonstrate that
software can be trusted by its users

11
Professional and Ethical Responsibility

► Software Process involves wider responsibilities than just the

application of technical skills
► Software Process must behave in honest and ethically
responsible ways to be respected as professionals
► Ethical behavior is more than simply upholding the law

12
Issues of Professional Responsibility

► Confidentiality
► Always respect confidentiality of employers or clients,
even when there is no formal confidentiality agreement
► Competence
► Never misrepresent one’s level of competence. never
accept work beyond one’s level of competence
► Intellectual property rights
► Ensure that the intellectual property of employers and
clients is protected
► Be aware of local laws governing use of intellectual
property such as patents and copyright
► Computer misuse
► Never use technical skills to misuse other people’s
computers

13
Software Process

► A structured set of activities required to develop a

software system.
► Fundamental Assumption:
► Good processes lead to good software
► Good processes reduce risk

14
Software Process

► Phases and actions to build, deliver, evolve software product

► Objectives
► Construct programs from idea to completion
► Produce reliable, predictable, and efficient software
► Difficult to automate because:
► Software production is a highly intellectual activity
► Software development involves:
► Interactions of individuals from various
backgrounds
► Interface to OS, hardware, databases … etc.
► Process models focus on the software lifecycle emphasizing
the process from start to finish

15
Modeling Motivation

► Increase in application complexity and requirements has led to

separation between developers and users
► Software now targets users without “computer expertise”
► Higher level of quality and reliability is needed
► Software development needs to:
► Manage complexity in modern applications
► Provide detailed careful analysis of user requirements
► Major goals of a process model are to:
► Determine appropriate stages
► Establish transition criteria for progressing from one stage
to another

16
Software Process Models
Software Process Models

A software process model is an abstract representation of a process.

► The waterfall model
► Separate and distinct phases of specification and
development (product focused)
► Evolutionary development
► Specification, development and validation are interleaved
e.g. XP (Beck), increment driven
► Component-based software engineering
► The system is assembled from existing components.
► Spiral (Boehm)
► driven by risk analysis and mitigation

18
Waterfall Method

► Unidirectional, no way back finish this step before moving to the

next

Requirements

Design

Implementation

Testing
Waterfall
method Deployment &
Maintenance

19
Waterfall Model

► First appeared in late 1950s - popularized in the 1970s

► Describes a sequential linear flow among phases
► Output of one phase is input to next
► Many variants of waterfall model; on which software categories
influence these variants:
► Customized software for particular customer
► Customized software for company
► Generalized application for commercial market
► Software production companies
► Define outputs for each phase
► Define methods to be used to produce outputs

20
Waterfall Model – Requirements Specification

► Purpose: Identify required qualities of application

► People: Interactions between end-users and software engineers
► States the required qualities (what) not (how) attained
► Produces a Software Requirements Specification (SRS)
document
► Provide detailed requirements and constraints
► Includes user manual with screen mockups
► SRS document contains
► Functional requirements – what product does
► Non-functional requirements
► Reliability (available, secure, integrity, safety, …)
► Accuracy of results, performance, …
► Operating/physical constraints, portability, …

21
Waterfall Model – Design

► Purpose: Decompose system into modules

► People: Software engineers and managers
► Produces a design specification document containing a
description of software architecture
► Decomposition usually has two phases:
► Preliminary design
► Detailed design
► Design specifications document must follow some standard (e.g.,
company’s standard, software standard …).
► Design alternatives proposed and evaluated
► Multiple ways to solve problem
► Evaluate with respect to requirements specifications

22
Waterfall Model - Coding and Module Testing

► Purpose: Actual coding and testing of software modules

► People: Software engineers and their managers
► Programming-in-the small
► Alternatives decided in design phase implemented and evaluated
► Usage of company wide standards
► Program layout, comments and headers, naming
conventions …
► Module testing
► Other activities include
► Code inspection for adherence to standards
► Check for software qualities (performance)

23
Waterfall Model - Integration and System Testing

► Purpose: Assemble application from individual components and

test the system/sub-systems
► People: Software engineers, managers, end-users
► Programming-in-the large
► Collections of modules and entire system tested
► Incremental testing
► Black-box testing
► Alpha testing – test under realistic conditions with end-users
► Usage of company wide standards
► Methods of integration and test data design
► Documentation of tests and results

24
Waterfall Model - Delivery and Maintenance

► Purpose:
► Purpose: Application distributed to users and supported via
maintenance/evolution
► People: Software-delivery personnel, software engineers, end-
users
► Two-stage delivery
► Beta testing: selective group of expected end-users to
shake out all bugs in the developed software
► Bugs are taken care of and then software product
delivered to customers

25
Other Activities in Waterfall Model

► Documentation
► Waterfall model is document-driven
► Output of each phase must be documented
► Company standards dictate document format
► Verification
► Emphasized during module and system testing
► Appropriate verification occurs via reviews and code
inspection
► The main goal is to monitor application quality throughout
development process to discover/remove errors
► Management
► Configuration and version management
► Human resources (personnel and organization)

26
Waterfall Model Evaluation

► Contributions to understanding software processes

► Software development must be disciplined, planned, and
managed
► Implementation delayed until objectives clearly understood
► Characteristics of waterfall model
► Linear: From beginning to end without backtracking
► Rigid:
► Results of each phase completed before
proceeding to next phase
► Assumes requirements and specifications finalized
► Monolithic: All planning is oriented to single delivery date

27
Waterfall Model Evaluation
► Problems with waterfall model
► Forces project planning to occur after limited analysis
performed
► The difficulty of accommodating change after the process is
underway
► Verification of requirements specifications document
performed by customer which is not very effective
► Unrealistic to assume all requirements frozen before
development starts
► Users often don’t know exact requirements, particularly
earlier in the process
► Does not stress anticipating changes
► Enforces standards based on producing particular documents
at specific times
28
Waterfall Waterfall Model Evaluation

► Therefore, this model is only appropriate when the requirements

are well-understood and changes will be fairly limited during the
design process
► The waterfall model is mostly used for large systems engineering
projects where a system is developed at several sites

29
Waterfall Process Model with Feedback

Requirements
analysis and
specification

Design

50 %
Coding and
module testing

Integration and
Optional system testing
Paths
Delivery and 50 %
maintenance

30
Evolutionary Process Model

► Studies shows the effectiveness of methodologies that produce a

product twice
► First version is throwaway to provide means for users to
offer feedback on exact requirements
► Second version developed using waterfall
► Evolutionary or incremental approach
► Emphasizes stepwise development
► Flexible and non-monolithic
► Postpones parts of some stages
► Several different variants of evolutionary model exist

31
Evolutionary Process Model

► Evolutionary process model can be described as “model whose

stages consist of expanding increments of an operational software
product, with the direction of evolution being determined by
operational experience”
► Delivered increment: Self-contained functional unit that is useful to
the customer
► Includes supporting material (documents, test plans,
training materials, etc.)
► Development strategy
► Deliver something to the real user
► Measure added value to user
► Adjust design and objectives accordingly
► Use increments to evolve toward desired product

32
Incremental Implementation Model Variant

► Implementation done incrementally

► Requires analysis and design emphasis on useful, deliverable
subsets/flexible interfaces
► Different plans are implemented, tested, and delivered at different
times
► Incremental implementation is only a partial solution
► May be missing functional (e.g., buttons don’t work)
► May simulate portions (e.g., files instead of databases)

33
Incremental Development & Delivery Model

► Incremental approach applied to all waterfall phases

► Achieves finer granularity in the process
► Waterfall model followed for different portions
► Increments developed after user feedback
► Users can understand what they actually need
► All evolutionary approaches
► Incorporate maintenance into every stage of the model
► Employ evolutionary prototype that is progressively
transformed into final application
► Prototyping helps software engineers understand user
needs
► Requires tools such as VISIO, rapid GUI tools, etc

34
Waterfall Assessing Evolutionary Models

► Problems
► Large time gap between requirements specification and delivery
► Emphasis on user interface not on product
► May miss functional requirement
► May underestimate database complexity/interactions
► Requires tools to manage process
► Lack of process visibility
► Systems are often poorly structured
► Special skills (e.g. in languages for rapid prototyping) may be
required
► Advantages
► Product may closely follow user requirements
► Supports anticipation of change
► More flexible than waterfall model

35
Evolutionary Models Applicability
► For small or medium-size interactive systems
► For parts of large systems (e.g. user interface)
► For short-lifetime systems

36
Transformation Model

► Roots in formal specification that views software as steps to

transform specifications to implementation
► Internal requirements are analyzed and formally specified
► Formal specification transformed into detailed, less
abstract formal description
► Repeat step 2 until description is executable by some
abstract processor
► Further transformations may be needed to increase
efficiency
► Transformations may be performed manually by software
engineers or by automated support systems

37
Transformation Model

Decisions & rationale

Reusable
components

Formal Lower level

Requirements Requirements specifications
specifications Optimization
analysis and
specification

Verification Tuning

Recording of
developmental history

38
Transformation Model

► Two main stages

► Requirements analysis for formal requirements
► Optimization for performance tuning
► Transformation controlled by software engineering
► Take advantage of reusable components
► Verify against user expectations
► Supported by software tools
► Tools for requirements verification, managing
reusable components, optimizing, configuration
management.
► Transformation model studied for small programs to
mathematically prove correctness

39
Spiral Model

► Purpose: Provide a framework for design production process

guided by risk levels
► Guiding principles: Level of risk (potential adverse circumstance)
► Risk management: “Discipline whose objectives are to identify,
address, and eliminate software risk items before they become
either threats to successful software operation or a major source
of expensive software rework.”
► Focus: mainly on identifying and eliminating high risk problems by
careful process design/assessment

40
Spiral Model

► Cyclical model is four stages:

► Identify objectives and design alternatives
► Evaluate alternatives and identify/deal with potential risks
► Develop and verify next level product
► Review results and plan for next iteration
► Allows unstated requirements to become part of specification of
next cycle
► Robustness approximates correctness more closely

41
The Spiral Model

42
The Spiral Model

43
Waterfall Model - Coding and Module Testing

► Purpose:

44
Waterfall Model - Coding and Module Testing

► Purpose:

45
Waterfall Model - Coding and Module Testing

► Purpose:

46
Waterfall Model - Coding and Module Testing

► Purpose:

47