Chapter 1

— Software : is defined as "computer programs, procedures, and possibly

associated documentation and data pertaining to the operation of a computer
system".

— Engineering : is the systematic application of scientific knowledge in creating

and building cost-effective solutions to practical problems in the service of
humankind.
— Software engineering : is that form of engineering that applies the principles
of computer science and mathematics to achieve cost-effective solutions to
software problems.

Software engineering framework :-

1- Goals :

• Cost effectiveness

• Usability

• Correctness

2- Activities :

• Requirement

• Design

• Implementation

• Validation

• Support
3- Principles :
• System design

• Software design

• Process support

Software design :-
• Modularity

• Abstraction

• Localization

• Uniformity

• Conformability

Software Life Cycle :-

1- Requirements analysis and definition
2- System and S/W design
3- Implementation and unit testing

4- System testing
5- Operation and maintenance

Software Products :-

• Generic Products

• Customized Products
Product Characteristics :-
• Maintainability

• Dependability

• Efficiency

• Acceptability
 Chapter 2
successful software project :-
- the scope of work to be done
- the risks to be incurred

- the resources to be required

- the tasks to be accomplished

- the milestones to be tracked

- the effort (cost) to be expended

- the schedule to be followed

Software Management Metrics :-

1) Measurement :
Software is measured for many reasons :
— To indicate the quality of the product
— To assess the productivity of the people who produce
— To assess the benefits (in terms of productivity and quality)
— To form a baseline for estimation;
— To help justify requests for new tools or additional training.

Types :
1- Direct measures :
— execution speed
— memory size
— defects reported over set period of time
2- Indirect measures :
— functionality
— quality
— complexity
— efficiency
— maintainability
— many other "abilities"

2) Software metrics .

Metric Categorization :-
— Size
— oriented metrics

— Function
— oriented metrics
— Human
— oriented metrics
— Technical metrics
— Quality metrics
— Productivity metrics

Rules :-
Productivity = KLOC / person-month Quality = defects / KLOC
Cost = $ / LOC

Documentation = pages of documentation / KLOC

Information domain characteristics:-
— Number of user inputs

— Number of user outputs

— Number of user inquiries

— Number of files
— Number of external interfaces

Software Project Estimation :-

— Delay estimation
— simple decomposition

— Develop an empirical model

— computerized estimation tools

Software Project Plan

1) Scope and purpose of document

2) Project objectives :
1. Objectives
2. Major functions
3. Performance issues
4. Management and technical constraints

3) Project estimates :
A. Historical data used for estimates
B. Estimation techniques
C. Estimates
4) Project risks :
A. Risk analysis :
1. Identification
2. Risk estimation
3. Evaluation
B. Risk management :
1. Identification
2. Risk monitoring procedures

5) Schedule :
A. Project work breakdown structure
B. Task network
C. Time-line chart, (Gantt chart)
D. Resource table

6) Project resources :
A. people
B. Hardware and software

7) Staff organization :
A. team structure (if applicable)
B. Management reporting

8) Tracking and control mechanisms

9) Appendices
 Chapter 3
Software Requirements Document :-
1.Introduction : should describe the need for the system rationale for the software
system.
2.Hardware : If the system is to be implemented on special hardware, this
hardware and its interfaces should be described.
3.The conceptual model : This section should describe the conceptual
model on which the requirements are based.
4.Functional requirements : The functional requirements of the system, that is,
the services provided for the user, should be described in this section.
5.Database requirements : The logical organization of the data used by the system
and its inter-relationships should be described here.
6.Non-functional requirements : The non-functional requirements of the system,
that is, the constraints under which the software must operate.
7.maintenance information : This section of the software requirements document
should describe the fundamental assumptions on which the system is based and
describe anticipated changes.
8.Glossary : This should define the technical terms used in the document.
9.Index : It may be desirable to provide more than one kind of index to the
document.

Model to be function of three elements :-

⎯ Functions : the information transforms in the system.

⎯ Data : the inputs and outputs of functions.

⎯ Control : the mechanism that activates functions in the desired sequence.

 There are two major problems, which sometimes arise when natural language is
used for requirements definition :

• Functional requirements, non-functional requirements system goals are not

clearly distinguished .

• Each paragraph may encompass several individual requirements in a single

statement. This makes consistency and completeness checking very difficult
indeed.

‫ض‬
: ‫اﻟﻤﺤﺎ�ة‬ ‫ﺻﻐ� و ﻣﻌﺮﻓتﺶ أﻋﻤﻠﻪ ﻣﻠﺨﺺ ﻟﻴﻨﻚ‬
‫ي‬ Chapter 4
https://drive.google.com/file/d/1UjUFS9AqZBcAWEaZK_Okoe528bXwa9G3/view?usp=drive_link
 Chapter 4
— For small systems, it may be possible to go directly from the requirement
definition to a detailed component design, but for large S/W systems, the design
activity may be split into three stages:

1) Associate abstract S/W components with the services set out in the
requirements definition and construct precise specifications for these components.

2) Construct a high-level design showing how these abstract S/W components

are related to each other.

3) Formula a detailed design for each abstract component.

— The specification phase should set out what the S/W do. A design should define
how the S/W function should be provided.

Formal S/W Specification :-

— Formal software specification implies that the specification is expressed in a
notation, which is mathematically sound.

— This means that both the syntax and the semantics of the specification
languages should “be formally designed”

There are three approaches to this problem:

1) The operational approach.
2) The denotations approach.
3) The axiomatic approach.

There are a number of advantages, which occur from using formal specifications
of S/W components:
1) Given a formal specification and a definition of programming language
semantic

2) Formal S/W specifications can be studied mathematically

3) Formal specifications are prosecutable by computers.

Interface Specifications : Interface specification involves specifying input and
output constraints
Operational Specifications : An operational specification defines the input / output
transformation explicitly.

Specifications of Data Abstractions :-

— For specifications to be complete, it is important to define the meaning of the
data type by specifying to the behavior of the type operations.

There are two approaches for the specification of abstract data types :
1) Specify the behavior of the type operations using an abstract model.
2) Algebraic approaches :
— has two parts :
1) An interface part which names the allowed operations & specifies the types of
their parameters.
2) An axioms part which defines the behavior of these operations.
 Chapter 5
Classification of Software Design Methodologies :
1- Top-Down functional design
2- Object oriented design

Design Notations : It was recognized that completely informal notations such

that flowcharts, which are closer to the programming language, are inadequate
vehicles for formulating and expressing system design .

Design Notation charts & diagrams :

— Data Flow Diagram (DFD) .
— HIPO charts .
— Structure diagrams .

Data Flow Diagram (DFD) :-

— DFD’s document describes how data input is transformed to be output, with
each stage in the diagram representing distinct transformation .
Examples (reading only):
Structure diagrams :-
Structure charts describe the programming system as a hierarchy of parts and
display the graphically, as a tree .

Design description language (DDL) :-

The lowest level of a software design is best described using some formal language.

— Also, high level language (Ada or Pascal) may be used with the advantage that
the design will be executable.

Disadvantages :-
• Hill's are not ready extended to include now concepts.

• Representation of some intuitively simple high level constructs sometimes

becomes detailed and confused.

• The designer will be influenced by the language constructs.

Top-down design :-

The design of software can not be formulated as a set of rules.

— Abstraction is the process of stripping and idea of its concert accompaniments .

— abstract entity without details of how that entity is actually realized .

The formulation and description of a software design stages:

• Study and understand the problem.

• Identify gross features of at least one possible solution.

• Construct a data flow diagram showing gross data transformations in the system.

• Construct a structure chart showing the problem units involved in the solution.

• Describe each abstraction used in the solution in a description language.

Object-oriented design :-

In object-oriented design, the software components are seen as objects rather

than function.

Design validation :-

Undetected errors and omissions are carried forward to the implementation phase
of the project and not detected until system testing can be extremely expensive to
correct.

The validation of software design is intended to achieve two objects :

1) the software design is "correct (verified)" this process is sometimes called

verification .

2) the software is "valid".

 Chapter 6
Programming depends on :

1) Individual Skill

2) Attention to detail

3) Knowledge about available tools in the best way

Programmer must understand :

1) the computer system

2) Some of theory programming

 Programming is Practical which can only be learned by experience

Programming Methodology :-
1) Top – Down development :
— requires that the program structure to be hierarchical.

— lowest level in the system hierarchy is implemented using basic programming

language facilities.

(Top-down development may be superior methodology because it results in the

creation of programs)

2) Bottom – up development :
is the converse of the above process implementation starts with the lower levels of the
system and the system is built up until, finally, the highest design level is implemented.

(In bottom-up development, the programmer creates basic building blocks and
uses these to build more complex blocks)
Information hiding : Control access to system data (allowed access only to program
objects)

Advantages :
• Hidden information will not be corrupted.

• Programs are more secure.

• Data representation may be changed without changing the program units.

Programming Style :-
1) Programming readability does not just depend on language facilities. The style

2) which a program is written determines its readability.

3) The creation of a readable and reliable program is a creative process and it is

impossible to lay down rigid rules governing programming style.

4) Recognition and avoidance of error prone language facilities that allow

compile-time and run-time checks to be carried out increase the overall reliability
of a program.

Program names :-
names of objects in a program should be closely (identical to the names of the
real-world)

Programming Environments :-
There are a number of different classes of programming environment such as
language-oriented environments and teaching environments.

The environment required supporting the development of large software systems.

A programming environment might provide the following facilities :
1) Communications
2) Target machine
3) Testing and debugging tools
4) Requirement specification and analysis tools
5) A computer aided design system
6) Project management tools

Program Portability :-
Programs should be written so that they may be implemented under more than
one computer / operating system configuration.

Machine architecture dependencies :-

— Different machines have different word lengths, different character sets and
different technique for representing integer and real numbers.

— It is extremely difficult to program in such a way that implicit dependencies on

machine word length are avoided.

Operating system dependencies :-

— Features of a high-level language program
— The major problem areas are libraries , files and input/output and job control
— A well-known and widely used operating system facility is the provision of
subroutines
— standardized libraries, which consist of routines associated with a particular
application
—Installation library, which consist of routines, submitted by user at a particular
installation.
There are a number of different problems, which can arise because of file system
incompatibilities :

1) Naming files may differ from system to system.

2) File system structure may differ from system to system

3) Different systems utilize different schemes

4) Classify files as data files, binary files, etc. other systems consider all files to be
files of character.

5) Most systems restrict the user to a maximum number of files , which may be in
use at any time.

6) There are a number of different files structuring mechanisms enforced by

different system.

7) Related to the structure of the file are the random-access primitives

supported by the system.
 Chapter 7
The Testing process :-
It is unrealistic to attempt to test systems as a single unit.
Testing Process stages:
1) Function testing (Unit testing) :
• Functions making up a module are tested to ensure that they operate correctly.
• Each function should have a single, clearly defined speciation.
• Function should not depend on other functions at the same level.

2) Module testing :
• A module is made up of a number of functions, which may cooperate with each
other.
• A module should be tested as a stand-alone entity, without the presence of other
system modules.

3) Sub-system testing :
• Modules are put together to form subsystems.

• This test should concentrate on testing module interfaces under the assumption
that the modules themselves are correct.

4) Sub-system testing :
• Sub-systems are integrated to make up the entire system.

• At this stage, the testing process is concerned with validating that the overall
system provides the function specified in the requirements and that the dynamic
characteristics of the system match those specified in the requirements
definition.
5) Acceptance testing :
• This is the process of testing the system with real data.

• This test demonstrates errors in the system requirement definition.

• It may demonstrate that the system does not exhibit the expected performance
and functionality.

Top-Down and Bottom-Up Testing :-

Top-Down testing starting at the sub-system level with modules represented by
stubs.

— First the functions making up a module are test individually.

— Then they are integrated to from a module and this is tested.

Note : Top-down tested is used in conjunction with top-down program

development so that a module is tested as soon as it is coded.

— In top-down testing, unnoticed design errors will be detected at an early stage

in the testing process. Early error detection before much of the system has been
implemented means that extensive redesign and reimplementation may be
avoided.

— Top-down testing has the advantage that a working system is available at an

early stage in the development process.

— Bottom-up testing the modules at the lower levels in the hierarchy, and then
working up the hierarchy of modules until the final module is tested. The
advantages of top-down testing are the disadvantages of bottom-up testing and
vice versa.

— Using a bottom-up approach to testing usually means that it is easier to create

test cases and observe test input.
The design of test cases :-
Testing of a programming system involves formulating a set of test cases, which
are akin to the real data that the system is intended to manipulate.

Testing tools :-
The process of system validation is the most expensive stage of software
development. For real-time system.

Types :
1) Test data generators :
— Test data generators are programs
— Given the specification of a database
— Test data generators can also be useful in a situation where the syntax of the
output from a system can be specified in a formal way.

2) Execution Flow Summarizers (EFS) :

EFS are programs used to analyze how many times each statement in some other
program has been executed.
— They are sometimes called dynamic analyzers and have two fundamental
parts.
— An instrumentation part which adds instrumentation statements to a program
either while it is being compiled or before compilation.
— A display part , which collects the information, provided by the instrumentation
statement and prints it in a form, which can be understood by the reader.

To instrument a program :
— Decision statements and loops :
• The instrumentation code is placed at the beginning of these identified
statements.

— A sequence of statements :
• The instrumentation section is placed at the beginning of sequence.
 Chapter 8
Software Quality Assurance (SQA) in an umbrella activity that applied throughout
the software engineering process.

— SQA encompasses the following jobs :

1) Analysis, design Coding and testing methods and tools.

2) Formal technical reviews that are applied during each software engineering
step.

3) Multitier testing strategy.

4) Control of software documentation and the changes made to it.

5) Procedure to assure compliance with software development standards.

6) Measurement.

7) Record keeping.

Software quality Factors :-

The factors that affect software quality can be categorized in two broad groups:

• Factors that can be directly measured.

• Factors that can be measured only indirectly.

Operational Characteristics :

— Correctness : the extent to which a program satisfies its specification and fulfills
the customer's mission activity.

— Reliability : the extent to which a program can be expected to perform its

intended function with required precision.

— Efficiency : the amount of computing resources and code required by a program

to perform its function.
— Integrity : the extent to which access to software or data by unauthorized
persons can be controlled.

— Usability : the effort required to learn operate, prepare input, and interpret
output of a program.

Product Revision Characteristics :-

— Maintainability : the effort required to locate and fix an error in a program.

— Flexibility : the effort required modifying an operational program.

— Testability : the effort required testing a program to ensure that it performs its
intended function.

Product Transition Characteristics :-

- Portability: the effort required transferring the program from one hardware
and/or software system environment to another.

- Reusability: the extent to which a program can be reassured in other applications

related to the packing and scope of the function that program performs.

- Interoperability: the effort required coupling one system to another.

Factors :-

It is difficult, and in the same time impossible, to develop direct measures of the
above quality factors. Therefore, a set of metrics are defined and used to develop
expressions for each of the factors according to the following relationship.

F = c1 × m1 + c2 × m2 + c3 × m3 + …. + cn × mn

Where F is a software quality factor

c are regression coefficients

mn are metrics that effect the quality factor

The following metrics are used :

1) Audibility : the ease with which conformance to standers can be checked.

2) Accuracy : the precision of computation and control.

3) Communication commonality : the degree to which standard protocols and

bandwidths are used.

4) Completeness : the degree to which full implementation of required function

have been achieved.

5) Conciseness : the compactness of the program in terms of lines of code.

6) Consistency : the use of uniform design and documentation technique

throughout the software development project.

7) Data commonality : the use of standard data structure and types throughout
the program.

8) Error tolerance : the damage that occurs when the programs encounter an
error.

9) Execution efficiency : the run—time performance of a program.

10) Expandability : the degree to which architectural, data, or procedural design

can be extended.

11) Generality : the breadth of potential application of program components.

12) Hardware independence : the degree to which the software is decoupled from
the hardware on which it operates.

13) Instrumentation : the degree to which the program monitors its own operation
and identifies errors that do occur.

14) Modularity : the functional independence of program components.

15) Operability : the ease of operation of a program.

16) Security : the availability of mechanisms that control or protect programs and
data.

17) Self—documentation : the degree to which the source cod2 provides

meaningful documentation.

18) Simplicity : the degree to which a program can be understood without

difficulty.

19) Software system independence : the degree to which the program is

independent of nonstandard programming language features, operating system
characteristics, and other environmental constraints.

20) Traceability : the ability to trace a design representation or actual program

component back to requirements.

21) Training : the degree to which the software assists in enabling new users to
apply the system.

Software Quality Activities :-

The SQA group serves as the customers' in-house representative.

Software Reviews :-
Software reviews are a 'filter' for the software engineering process.