Chapter 1 Introduction to software engineering

Software issue
Ethical
Software meaning
Software related activity
- Software specification
- Software validation
- Software

Software failure because:

1. Increasing system complexity As new software engineering techniques help us to build larger, more
complex systems, the demands change. Systems have to be built and delivered more quickly; larger,
even more complex systems are required; and systems have to have new capabilities that were
previously thought to be impossible. New software engineering techniques have to be developed to
meet new the challenges of delivering more complex software.
2. Failure to use software engineering methods It is fairly easy to write computer programs without
using software engineering methods and techniques. Many companies have drifted into software
development as their products and services have evolved. They do not use software engineering
methods in their everyday work. Consequently, their software is often more expensive and less reliable
than it should be. We need better software engineering education and training to address this problem.

Problem in software development

- misunderstand the requirements
- Hard to expand and improve
- Bad documentation
- Bad quality
- Exceed the time
- Exceed the budget

Software engineering is concerned with theory, method and tools for professional software
development.

Aim of software engineering is:

On time
Within budget
Reliable
Complete

Importance of software engineering

Software engineering is concerned with cost-effective software development to produce reliable and
trustworthy systems economically and quickly.

60% cost is development cost and 40% cost is testing cost

Software engineering is important for two reasons:
1. More and more, individuals and society rely on advanced software systems. We need to be able to
produce reliable and trustworthy systems economically and quickly.
2. It is usually cheaper, in the long run, to use software engineering methods and techniques for
professional software systems rather than just write programs as a personal programming project.
Failure to use software engineering method leads to higher costs for testing, quality assurance, and
long-term maintenance.

Software issues
Heterogeneity
Increasingly, systems are required to operate as distributed systems across networks that include
different types of computer and mobile devices.

Business and social change

Business and society are changing incredibly quickly as emerging economies develop and new
technologies become available. They need to be able
to change their existing software and to rapidly develop new software.
Security and trust
As software is intertwined with all aspects of our lives, it is essential that we can trust that software.

Scale
Software has to be developed across a very wide range of scales, from very small embedded systems
in portable or wearable devices through to Internet-scale, cloud-based systems that serve a global
community.

Software engineering activity:

Software specification, where customers and engineers define the software that is to be produced and
the constraints on its operation.

Software development, where the software is designed and programmed.

Software validation, where the software is checked to ensure that it is what the customer requires.

Software evolution, where the software is modified to reflect changing customer and market
requirements.

Generic product
Stand-alone systems that are marketed and sold to any customer who wishes to buy them.
The specification of what the software should do is owned by the software developer and decisions on
software change are made by the developer.

Customized product
Software that is commissioned by a specific customer to meet their own needs.
The specification of what the software should do is owned by the customer for the software and they
make decisions on software changes that are required.

Application types:
Embedded system
These are software control systems that control and manage hardware devices. Numerically, there are
probably more embedded systems than any other type of system. Examples of embedded systems
include the software in a mobile (cell) phone, software that controls antilock braking in a car, and
software in a microwave oven to control the cooking process.

System of system
These are systems that are composed of a number of other software systems.

Stand-alone application
These are application systems that run on a local computer, such as a PC. They include all necessary
functionality and do not need to be connected to a network. Examples of such applications are office
applications on a PC, CAD programs, photo manipulation software, travel apps, productivity apps, and
so on.

Interactive transaction-based application

Applications that execute on a remote computer and are accessed by users from their own PCs or
terminals. These include web applications such as e-commerce applications where you interact with a
remote system to buy goods and services.

Batch processing system

These are business systems that are designed to process data in large batches. They process large
numbers of individual inputs to create corresponding outputs. Examples of batch systems are periodic
billing systems, such as phone billing systems, and salary payment systems

Entertainment system
These are systems that are primarily for personal use and which are intended to entertain the user.
Most of these systems are games of one kind or another, which may run on special-purpose console
hardware. The quality of the user interaction offered is the most important distinguishing characteristic
of entertainment systems.

Systems for modelling and stimulation

These are systems that are developed by scientists and engineers to model physical processes or
situations, which include many, separate, interacting objects. These are often computationally intensive
and require high-performance parallel systems for execution.

Data collection system

These are systems that collect data from their environment using a set of sensors and send that data to
other systems for processing. “Big data” analysis may involve cloud-based systems carrying out
statistical analysis and looking for relationships in the collected data.

Fundamental principles of software engineering

Systems should be developed using a managed and understood development process. Of course,
different processes are used for different types of software.

Dependability and performance are important for all types of system.

Understanding and managing the software specification and requirements (what the software should do)
are important.

Where appropriate, you should reuse software that has already been developed rather than write new
software.

SE ethics
1. Confidentiality You should normally respect the confidentiality of your employers or clients
regardless of whether or not a formal confidentiality agreement has been signed.
2. Competence You should not misrepresent your level of competence. You should not knowingly
accept work that is outside your competence.
3. Intellectual property rights You should be aware of local laws governing the use of intellectual
property such as patents and copyright. You should be careful to ensure that the intellectual property of
employers and clients is protected.
4. Computer misuse You should not use your technical skills to misuse other people’s computers.
Computer misuse ranges from relatively trivial (game playing on an employer’s machine) to extremely
serious (dissemination of viruses or other malware).

software engineers shall adhere to the following Eight Principles:

1. PUBLIC — Software engineers shall act consistently with the public interest.
2. CLIENT AND EMPLOYER — Software engineers shall act in a manner that is in the
best interests of their client and employer consistent with the public interest.
3. PRODUCT — Software engineers shall ensure that their products and related
modifications meet the highest professional standards possible.
4. JUDGMENT — Software engineers shall maintain integrity and independence in their
professional judgment.
5. MANAGEMENT — Software engineering managers and leaders shall subscribe to and
promote an ethical approach to the management of software development and
maintenance.
6. PROFESSION — Software engineers shall advance the integrity and reputation of
the profession consistent with the public interest.
7. COLLEAGUES — Software engineers shall be fair to and supportive of their
colleagues.
8. SELF — Software engineers shall participate in lifelong learning regarding
the practice of their profession and shall promote an ethical approach to the
practice of the profession.
System engineering
Specifying, designing, implementing, validating, deploying and maintaining socio-technical systems.
Concerned with the services provided by the system, constraints on its construction and operation and
the ways in which it is used.
Computer science is concerned with the theories and methods that underlie computers and software
systems, whereas software engineering is concerned with the practical problems of producing software.

Essential attributes for quality product:

Acceptability
Software must be acceptable to the type of users for which it is designed. This means that it must be
understandable, usable, and compatible with other systems that they use.

Dependability and security

Software dependability includes a range of characteristics including reliability, security, and safety.
Dependable software should not cause physical or economic damage in the event of system failure.
Software has to be secure so that malicious users cannot access or damage the system.
Efficiency
Software should not make wasteful use of system resources such as memory and processor cycles.
Efficiency therefore includes responsiveness, processing time, resource utilization, etc.
Maintainability
Software should be written in such a way that it can evolve to meet the changing needs of customers.
This is a critical attribute because software change is an inevitable requirement of a changing business
environment.

Software engineering is an engineering discipline that is concerned with all aspects of software
production from the early stages of system specification through to maintaining the system after it has
gone into use. In this definition, there are two key phrases:
1.
Engineering discipline Engineers make things work. They apply theories, methods, and tools where
these are appropriate. However, they use them selectively and always try to discover solutions to
problems even when there are no applicable theories and methods. Engineers also recognize that they
must work to organizational and financial constraints so they look for solutions within these
constraints.
2.
All aspects of software production Software engineering is not just concerned with the technical
processes of software development. It also includes activities such as software project management and
the development of tools, methods, and theories to support software production.

Software engineering is important for two reasons:

More and more, individuals and society rely on advanced software systems. We need to be able to
produce reliable and trustworthy systems economically and quickly.

It is usually cheaper, in the long run, to use software engineering methods and techniques for software
systems rather than just write the programs as if it was a personal programming project. For most types
of systems, the majority of costs are the costs of changing the software after it has gone into use

This radical change in software organization has, obviously, led to changes in the ways that web-based
systems are engineered. For example:
1. Software reuse has become the dominant approach for constructing web-based systems. When
building these systems, you think about how you can assemble them from pre-existing software
components and systems.

2. It is now generally recognized that it is impractical to specify all the requirements for such systems
in advance. Web-based systems should be developed and delivered incrementally.

3. User interfaces are constrained by the capabilities of web browsers. Although technologies such as
AJAX mean that rich interfaces can be created within a web browser, these technologies are still
difficult to use. Web forms with local scripting are more commonly used. Application interfaces on
web-based systems are often poorer than the specially designed user interfaces on PC system products.
Chapter 2 Software process model
Software process activity:
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.

SDLC( Software development lifecycle)

Have 7 steps:
Planning
Requirements
Design
Software development
Testing
Deployment
Operation maintenance

Software process model:

Process descriptions may also include:
- Products, which are the outcomes of a development activity;
- Roles, which reflect the responsibilities of the people involved in the process;
- Pre- and post-conditions, which are statements that are true before and after a process activity has
been enacted or a product produced.
- Notation: activities, products
Software process model is divided by two model:
Plan-driven model
- Plan-driven processes are processes where all of the process activities are planned in advance and
progress is measured against this plan.
- Waterfall model is plan driven model
Separate and distinct phases of specification and development.
There are separate identified phases in the waterfall model:
Requirements analysis and definition The system’s services, constraints, and goals are established by
consultation with system users. They are then defined in detail and serve as a system specification.
2.
System and software design The systems design process allocates the requirements to either hardware
or software systems by establishing an overall system architecture. Software design involves
identifying and describing the fundamental software system abstractions and their relationships.
3.
Implementation and unit testing During this stage, the software design is realized as a set of programs
or program units. Unit testing involves verifying that each unit meets its specification.
4.
Integration and system testing The individual program units or programs are integrated and tested as a
complete system to ensure that the software requirements have been met. After testing, the software
system is delivered to the customer.
5.
Operation and maintenance Normally (although not necessarily), this is the longest life cycle phase.
The system is installed and put into practical use. Maintenance involves correcting errors which were
not discovered in earlier stages of the life cycle, improving the implementation of system units and
enhancing the system’s services as new requirements are discovered.

The main drawback of the waterfall model is the difficulty of accommodating change after the process
is underway. In principle, a phase has to be complete before moving onto the next phase.
Incremental development
May be plan driven or agile, Specification, development and validation are interleaved.
Incremental development has three important benefits, compared to the waterfall
model:
1. The cost of accommodating changing customer requirements is reduced. The amount of analysis and
documentation that has to be redone is much less than is required with the waterfall model.
2. It is easier to get customer feedback on the development work that has been done. Customers can
comment on demonstrations of the software and see how much has been implemented. Customers find
it difficult to judge progress from software design documents.
3. More rapid delivery and deployment of useful software to the customer is possible, even if all of the
functionality has not been included. Customers are able to use and gain value from the software earlier
than is possible with a waterfall process.

From a management perspective, the incremental approach has two problems:

1. The process is not visible. Managers need regular deliverables to measure progress. If systems are
developed quickly, it is not cost-effective to produce documents that reflect every version of the
system.
2. System structure tends to degrade as new increments are added. Unless time and money is spent on
refactoring to improve the software, regular change tends to corrupt its structure. Incorporating further
software changes becomes increasingly difficult and costly

- Reuse oriented software engineering, maybe agile or plan driven. The system is assembled from
existing components.
Process stages
Component analysis Given the requirements specification, a search is made for components to
implement that specification. Usually, there is no exact match and the components that may be used
only provide some of the functionality required.
2.
Requirements modification During this stage, the requirements are analyzed using information about
the components that have been discovered. They are then modified to reflect the available components.
Where modifications are impossible, the component analysis activity may be re-entered to search for
alternative solutions.
3.
System design with reuse During this phase, the framework of the system is designed or an existing
framework is reused. The designers take into account the components that are reused and organize the
framework to cater for this. Some new software may have to be designed if reusable components are
not available.
4.
Development and integration Software that cannot be externally procured is developed, and the
components and COTS systems are integrated to create the new system. System integration, in this
model, may be part of the development process rather than a separate activity.

There are three types of software component that may be used in a reuse-oriented
process:
1. Web services that are developed according to service standards and which are available for remote
invocation.
2. Collections of objects that are developed as a package to be integrated with a component framework
such as .NET or J2EE.
3. Stand-alone software systems that are configured for use in a particular environment.

Based on systematic reuse where systems are integrated from existing components or COTS
(Commercial-off-the-shelf) systems.

Agile process model

Agile methodology allows for flexibility, adaptability, and incremental development, which can help in
meeting the project's tight deadline. By breaking down the project into smaller, manageable tasks and
iterations, the team can deliver working software in a timely manner while ensuring continuous
feedback and collaboration with stakeholders.

Agile manifesto
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Agile methods:
Focus on the code rather than the design
Are based on an iterative approach to software development
Are intended to deliver working software quickly and evolve this quickly to meet changing
requirements.

Agile principles
Customer i Customers should be closely involved throughout the development process.
nvolvemen
t Their role is provide and prioritize new system requirements and to evaluate the iterations of the system.

Incrementa The software is developed in increments with the customer specifying the requirements to be included
l delivery
in each increment.

People not The skills of the development team should be recognized and exploited. Team members should
process
be left to develop their own ways of working without prescriptive processes.

Embrace c Expect the system requirements to change and so design the system to accommodate these changes.
hange

Maintain si Focus on simplicity in both the software being developed and in the development process.
mplicity
Wherever possible, actively work to eliminate complexity from the system.

There are two related approaches that may be used to reduce the costs of rework:
1. Change avoidance, where the software process includes activities that can anticipate possible
changes before significant rework is required. For example, a prototype system may be developed to
show some key features of the system to customers. They can experiment with the prototype and refine
their requirements before committing to high software production costs.

2. Change tolerance, where the process is designed so that changes can be accommodated at relatively
low cost. This normally involves some form of incremental development. Proposed changes may be
implemented in increments that have not yet been developed. If this is impossible, then only a single
increment (a small part of the system) may have to be altered to incorporate the change.

Two ways of coping with change and changing system requirements. These are:
1. System prototyping, where a version of the system or part of the system is developed quickly to
check the customer’s requirements and the feasibility of some design decisions. This supports change
avoidance as it allows users to experiment with the system before delivery and so refine their
requirements. The number of requirements change proposals made after delivery is therefore likely to
be reduced.
2. Incremental delivery, where system increments are delivered to the customer for comment and
experimentation. This supports both change avoidance and change tolerance. It avoids the premature
commitment to requirements for the whole system and allows changes to be incorporated into later
increments at relatively low cost.

However, this is usually unwise:

1. It may be impossible to tune the prototype to meet non-functional requirements, such as
performance, security, robustness, and reliability requirements, which were ignored during prototype
development.
2. Rapid change during development inevitably means that the prototype is undocumented. The only
design specification is the prototype code. This is not good enough for long-term maintenance.
3. The changes made during prototype development will probably have degraded the system structure.
The system will be difficult and expensive to maintain.
4. Organizational quality standards are normally relaxed for prototype development

Incremental delivery has a number of advantages:

1. Customers can use the early increments as prototypes and gain experience that informs their
requirements for later system increments. Unlike prototypes, these are part of the real system so there is
no re-learning when the complete system is available.
2. Customers do not have to wait until the entire system is delivered before they can gain value from it.
The first increment satisfies their most critical requirements so they can use the software immediately.
3. The process maintains the benefits of incremental development in that it should be relatively easy to
incorporate changes into the system.
4. As the highest-priority services are delivered first and increments then integrated, the most important
system services receive the most testing. This means that customers are less likely to encounter
software failures in the most important parts of the system.

However, there are problems with incremental delivery:

1. Most systems require a set of basic facilities that are used by different parts of the system. As
requirements are not defined in detail until an increment is to be implemented, it can be hard to identify
common facilities that are needed by all increments.
2. Iterative development can also be difficult when a replacement system is being developed. Users
want all of the functionality of the old system and are often unwilling to experiment with an incomplete
new system. Therefore, getting useful customer feedback is difficult.
3. The essence of iterative processes is that the specification is developed in conjunction with the
software. However, this conflicts with the procurement model of many organizations, where the
complete system specification is part of the system development contract.

Chapter 3 Requirements
Requirements engineering process
Feasibility study
Requirements elicitation and analysis
Requirements specification
Requirements validation

Extreme programming is what?

because the approach was developed by pushing recognized good practice, such as iterative
development, to “extreme” levels. For example, in XP, several new versions of a system may be
developed by different programmers, integrated, and tested in a day.

Collective ownership
The pairs of developers work on all areas of the system, so that no islands of expertise develop and all
the developers take responsibility for all of the code. Anyone can change anything.
Continuous integration
As soon as the work on a task is complete, it is integrated into the whole system. After any such
integration, all the unit tests in the system must pass.
Incremental planning
Requirements are recorded on “story cards,” and the stories to be included in a release are determined
by the time available and their relative priority. The developers break these stories into development
“tasks.”
On-site customer
A representative of the end-user of the system (the Customer) should be available full time for the use
of the XP team. In an extreme programming process, the customer is a member of the development
team and is responsible for bringing system requirements to the team for implementation.
Pair programming
Developers work in pairs, checking each other's work and providing the support to always do a good
job.
Refactoring
All developers are expected to refactor the code continuously as soon as potential code improvements
are found. This keeps the code simple and maintainable.
Simple design
Enough design is carried out to meet the current requirements and no more.
Small releases
The minimal useful set of functionality that provides business value is developed first. Releases of the
system are frequent and incrementally add functionality to the first release.
Sustainable pace
Large amounts of overtime are not considered acceptable, as the net effect is often to reduce code
quality and medium-term productivity.
Test first development
An automated unit test framework is used to write tests for a new piece of functionality before that
functionality itself is implemented.

Scrum
A daily meeting of the Scrum team that reviews progress and prioritizes
work to be done that day. Ideally, this should be a short face-to-face
meeting that includes the whole team.

Sprints
A development iteration. Sprints are usually 2 to 4 weeks long.

Requirements
Functional requirements

Non functional requirements

Product requirements
Requirements which specify that the delivered product must behave in a particular way e.g. execution
speed, reliability, etc.

Organizational requirements
Requirements which are a consequence of organizational policies and procedures e.g. process
standards used, implementation requirements, etc.

External requirements
Requirements which arise from factors which are external to the system and its development process,
e.g. interoperability requirements, legislative requirements, etc

four activities that may be part of the design process for information systems:
Architectural design, where you identify the overall structure of the system, the principal components
(sometimes called sub-systems or modules), their relationships, and how they are distributed.
Interface design, where you define the interfaces between system components. This interface
specification must be unambiguous. With a precise interface, a component can be used without other
components having to know how it is implemented. Once interface specifications are agreed, the
components can be designed and developed concurrently.

Component design, where you take each system component and design how it will operate. This may
be a simple statement of the expected functionality to be implemented, with the specific design left to
the programmer. Alternatively, it may be a list of changes to be made to a reusable component or a
detailed design model. The design model may be used to automatically generate an implementation.

Database design, where you design the system data structures and how these are to be represented in a
database. Again, the work here depends on whether an existing database is to be reused or a new
database is to be created.

User of the requirements document

Structured of the requirements document:

Preface: This should define the expected readership of the document and describe its version history,
including a rationale for the creation of a new version and a summary of the changes made in each
version.
Introduction: This should describe the need for the system.
Glossary: This should define the technical terms used in the document.
User requirements definition: Here, you describe the services provided for the user. The
nonfunctional system requirements should also be described in this section.
System architecture: present a high-level overview of the anticipated system architecture, showing
the distribution of functions across system modules. Architectural components
that are reused should be highlighted.

Requirements engineering process

However, there are a number of generic activities common to all processes
Requirements elicitation
Requirements analysis
Requirements validation
Requirements management

The processes used for RE vary widely depending on the application domain, the people involved and
the organisation developing the requirements.
Activity of requirements elicitation:
Requirements discovery
Interacting with stakeholders to discover their requirements. Domain requirements are also
discovered at this stage.
Requirements classification and organization
Groups related requirements and organizes them into coherent clusters.
Prioritization and negotiation
Prioritizing requirements and resolving requirements conflicts.
Requirements specification
Requirements are documented and input into the next round of the spiral.

Requirements validation activity:

Requirements reviews
Systematic manual analysis of the requirements.
Prototyping
Using an executable model of the system to check requirements. Covered in Chapter 2.
Test-case generation
Developing tests for requirements to check testability.

Requirements management is the process of managing changing requirements during the

requirements engineering process and system development.
New requirements emerge as a system is being developed and after it has gone into use.
Requirements management decisions:
Requirements identification Each requirement must be uniquely identified so that it can be cross-
referenced with other requirements.
A change management process This is the set of activities that assess the impact and cost of changes.
I discuss this process in more detail in the following section.
Traceability policies These policies define the relationships between each requirement and between
the requirements and the system design that should be recorded.
Tool support Tools that may be used range from specialist requirements management systems to
spreadsheets and simple database systems.

Metrics to non functional requirements:

Speed
 Processed transactions/second
 User/event response time
 Screen refresh time
Size
 Mbytes
 Number of ROM chips
Ease of use
 Training time
 Number of help frames
Reliability
 Mean time to failure
 Probability of unavailability
 Rate of failure occurrence
 Availability
Robustness
 Time to restart after failure
 Percentage of events causing failure
 Probability of data corruption on failure
Portability
 Percentage of target dependent statements
 Number of target systems

Design graphical model

Possible models
Data-flow model - show data transformation
Entity-relation-attribute model - describing the logical data structures
Structural model - showing system components and their interactions
Object models

Design method:
Structured design - supported with CASE tools
JSD Jackson System Development

Design description is use graphical notation to show relationship between components, informal text,
natural language to describe so that customer and user can understand, Program description
languages. Based on programming languages but with more flexibility to represent abstract concepts

Design strategy:
Functional design
The system is designed from a functional viewpoint. The system state is centralised and shared
between the functions operating on that state

Object-oriented design
The system is viewed as a collection of interacting objects. The system state is de-centralised and each
object manages its own state. Objects may be instances of an object class and communicate by
exchanging methods

However, there are costs associated with reuse:

1. The costs of the time spent in looking for software to reuse and assessing whether or not it meets
your needs. You may have to test the software to make sure that it will work in your environment,
especially if this is different from its development environment.
2. Where applicable, the costs of buying the reusable software. For large off-theshelf systems, these
costs can be very high.
3. The costs of adapting and configuring the reusable software components or systems to reflect the
requirements of the system that you are developing.
4. The costs of integrating reusable software elements with each other (if you are using software from
different sources) and with the new code that you have developed. Integrating reusable software from
different providers can be difficult and expensive because the providers may make conflicting
assumptions about how their respective software will be reused.

Cohesion and Copuling

Introduction: The purpose of the Design phase in the Software Development Life Cycle is to
produce a solution to a problem given in the SRS(Software Requirement Specification) document.
The output of the design phase is a Software Design Document (SDD).
Spiral model:
Each loop in the spiral is split into four sectors:
1.
Objective setting Specific objectives for that phase of the project are defined. Constraints on the
process and the product are identified and a detailed management plan is drawn up. Project risks are
identified. Alternative strategies, depending on these risks, may be planned.
2.
Risk assessment and reduction For each of the identified project risks, a detailed analysis is carried out.
Steps are taken to reduce the risk. For example, if there is a risk that the requirements are inappropriate,
a prototype system may be developed.
3.
Development and validation After risk evaluation, a development model for the system is chosen. 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, and so on. If the main identified risk is sub-system integration, the
waterfall model may be the best development model to use.
4.
Planning The project is reviewed and a decision made whether to continue with a further loop of the
spiral. If it is decided to continue, plans are drawn up for the next phase of the project.

Chapter 4 Software testing

Software testing is intended to show that a program does what it is intended to do and to discover
program defects before it is put into use.

Error : It is a human action that produces the incorrect result that produces a fault.
Bug : The presence of error at the time of execution of the software.
Fault : State of software caused by an error.
Failure : Deviation of the software from its expected result. It is an event.

Verification and validation

Verification means are we building the product right?

Validation is means are we building the right product?

Test cases is a table of questions to test whether each functional have perform well or not
Test plan is plan that carry out before testing, It is a systematic approach to test a system i.e.
software. The plan typically contains a detailed understanding of what the eventual testing workflow
will be
Test cases
It is a specific procedure of testing a particular requirement.
It will include:
 Identification of specific requirement tested
 Test case success/failure criteria
 Specific steps to execute test
 Test data

Testing techique
Black box testing
- is the user didn’t have knowledge about the internal content of the system, the user only test the
function and interface only. Tests are based on requirements and functionality.

White box testing

- the user have knowledge about the internal code of the system and actually white box means the
user can see the internal content of the sytsem. Tests are based on coverage of code
statements, branches, paths, conditions.
Have 3 main testing
Development testing
- the system is tested during development to discover bugs and defects. Carrying out by the
development team
Development testing have 3 testing skill:
Unit testing, where individual program units or object classes are tested. Unit testing should focus on
testing the functionality of objects or methods.
Unit testing is the process of testing individual components in isolation.
It is a defect testing process.
Units may be:
Individual functions or methods within an object
Object classes with several attributes and methods
Composite components with defined interfaces used to access their functionality.

Component/integration testing, where several individual units are integrated to create composite
components. Component testing should focus on testing component interfaces.

System testing, where some or all of the components in a system are integrated and the system is
tested as a whole. System testing should focus on testing component interactions.

User testing
- users or potential users of a system test the system in their own environment. is a stage in the
testing process in which users or customers provide input and advice on system testing. U ser testing
is essential The reason for this is that influences from the user’s working environment have a major
effect on the reliability, performance, usability and robustness of a system. These cannot be
replicated in a testing environment.

Types of user testing

Alpha testing
Users of the software work with the development team to test the software at the developer’s site.

Beta testing
A release of the software is made available to users to allow them to experiment and to raise
problems that they discover with the system developers.

Acceptance testing
Customers test a system to decide whether or not it is ready to be accepted from the system
developers and deployed in the customer environment. Primarily for custom systems.

Release testing
- a separate testing team test a complete version of the system before it is released to users.

Testing strategy:
Partition testing
Guideline-based testing

Interface testing
Performance testing is part of the release testing may involve testing the emergent properties of a
system, such as performance and reliability.

Stress testing is a form of performance testing where the system is deliberately overloaded to test its
failure behavior.

Testing only can show the presence if error, cannot state that the system no remaining error

In order to be cost effective, the testing must be concentrated on areas where it will be most
effective.

Chapter 5 Project Management

Factors of project management:

 Company size
 SOftware customer
 Software size
 Software type.
 Organizational culture.
 Software development processes.

Project management activity

Project planning - Project managers are responsible for planning, estimating and scheduling.
Risk management - Project managers assess the risks, monitor these risks and take action when
problems arise.
People management - Choose people for their team and establish ways of working that leads to
effective team performance.
Reporting
Proposal writing

Deliverables of project management are project results delivered to customers.

Software pricing strategy

Under pricing
A company may underprice a system in order to gain a contract that allows them to retain staff for
future opportunities
A company may underprice a system to gain access to a new market area

Increased pricing
The price may be increased when a buyer wishes a fixed-price contract and so the seller increases the
price to allow for unexpected risks

Pricing to win
The software is priced according to what the software developer believes the buyer is willing to pay
If this is less than the development costs, the software functionality may be reduced accordingly with
a view to extra functionality being added in a later release
Additional costs may be added as the requirements change and these may be priced at a higher level
to make up the shortfall in the original price

It means that if the price is low than the development cost, the software developer can reduce the
functionality first, and then if the buyer need to add the extra functionality then software developer
can priced at a higher level
Factors affecting software pricing
Retain （保留）
Uncertainly (犹豫不决）
Volatility (易变）

Risk classification:
Project risk – affect the project schedule or resources.
Product risk – affect quality and performance of the software being developed.
Business risk – affect the organization that develops or procures the software.

Risk strategies
Avoidance strategies – To reduce the probability that the risk will happen
Minimization strategies – To reduce the impact of the risk on the project or product.
Contingency plans – Plans on how to deal with the risk if it happens

Four critical factors that influence relationship between manager and people in organization:
Consistency - Team members should all be treated in a comparable way without favoritism or
discrimination.
Respect - Different team members have different skills and these differences should be respected.
Inclusion - Involve all team members and make sure that people’s views are considered.
Honesty - Be honest about what is going on well in a project and vice-versa.
Chapter6 Quality management
A quality plan sets out
the desired product qualities
the product quality assessment processes or procedures
the most significant quality attributes
the organisational standards should be applied (and, where necessary, define new standards to be
used)

Product and process standard

Product standards Process standards

Design review form Design review conduct

Requirements document Submission of new code for

structure system building

Method header format Version release process

Java programming style Project plan approval process

Project plan format Change control process

Change request form Test recording process

There are different types of review with different objectives

Inspections for defect removal (product);
Reviews for progress assessment (product and process);
Quality reviews (product and standards).
Chapter 7 software security

Security terminology
Term Definition

Something of value which has to be protected such as software system, data, etc
Asset
.

Possible loss or harm to a computing system. Examples: loss or damage to data,

Exposure（暴露）
loss of time and effort if recovery is necessary after a security breach.

A weakness in a computer-based system that may be exploited to cause loss or

Vulnerability
harm.

An exploitation of a system’s vulnerability from outside the system and is a deli

Attack
berate attempt to cause some damage.

Threats Circumstances that have potential to cause loss or harm.

A protective measure that reduces a system’s vulnerability. Example: En

Control cryption is an example of a control that reduces a vulnerability of a weak
access control system

Damage from insecurity

Denial of service
The system is forced into a state where normal services are unavailable or where service provision( 供
应） is significantly degraded(弱化)。
Corruption 腐败 of programs or data
The programs or data in the system may be modified in an unauthorised way.
Disclosure( 揭露） of confidential information
Information that is managed by the system may be exposed to people who are not authorised to read
or use that information.

Identificat
Intrusion detection
ion
Authentic
Non-repudiation（ 否认）
ation
Authorizat
Privacy
ion
Immunity Security auditing
 Integrity System maintenance security

Security assurance

Vulnerability avoidance
- The system Is designed so that vulnerabilities do not occur. For example, if there is no external
network connection then external attack is impossible.

Attack detection and elimination

- the system is designed so that attacks on vulnerabilities are detected and neutralised before they
result in an exposure. For example, virus checkers find and remove viruses before they infect a system

Exposure limitation and recovery

- The system is designed so that the adverse(不利） consequences of a successful attack are
minimised. For example, a backup policy allows damaged information to be restored.

risk management involves:

Preliminary(预备） risk assessment – identify generic security risks
Design risk assessment – performed during development life cycle
Operational risk assessment – conducted when the system is in use.
Asset Value Exposure
The information sy High. Required to High. Financial loss as clinics may have to be cancelled.
stem support all clinical
consultations. Pote Costs of restoring system. Possible patient harm if
ntially safety-
critical. treatment cannot be prescribed.

The patient databa High. Required to High. Financial loss as clinics may have to be cancelled.
se support all clinical
consultations. Pote Costs of restoring system. Possible patient harm if
ntially safety-
critical. treatment cannot be prescribed.

An individual pati Normally low alth Low direct losses but possible loss of reputation.
ent record ough may be high
for specific high-
profile patients.

Types of security requirements

Type Specification of requirements

Identification the needs to identify its users before interacting with them.
 Authentication how users are identified.

Authorization the privileges and access permissions of identified users.

Immunity how a system should protect itself against viruses, worms, and similar

threats.

Integrity how data corruption can be avoided.

Intrusion detection what mechanisms should be used to detect attacks on the system.

Nonrepudiation that a party in a transaction cannot deny its involvement in that transaction.

Privacy how data privacy is to be maintained.

Security auditing how system use can be audited and checked.

System maintenance how an application can prevent authorized changes from accidentally
security
defeating its security mechanisms.

Two fundamental issues have to be considered when designing an architecture for security.
Protection - How should the system be organized so that critical assets can be protected against
external attack?
Distribution - How should system assets be distributed so that the effects of a successful attack are
minimized?

Activity in survivability analysis:

System understanding
Review goals, requirements and architecture

Critical service identification

Identify services that must be maintained

Attack simulation
Devise attack scenarios and identify components affected

Survivability analysis
Identify survivability strategies to be applied

Survivability strategy:
Resistance (抵抗）
Avoiding problems by building capabilities into the system to resist attacks
Recognition
Detecting problems by building capabilities into the system to detect attacks and failures and assess
the resultant damage
Recovery
Tolerating problems by building capabilities into the system to deliver services whilst under attack

Chapter 8 Configuration management (配置管理）

What is meaning of configuration management?

Configuration management (CM) is concerned with the policies, processes, and tools for managing
changing software systems.
useful for individual projects as it is easy for one person to forget what changes have been made. It is
essential for team projects where several developers are working at the same time on a software
system.

1. Version control This involves keeping track of the multiple versions of system components and
ensuring that changes made to components by different developers do not interfere with each other.

2. System building This is the process of assembling program components, data, and libraries, then
compiling and linking these to create an executable system.

3. Change management This involves keeping track of requests for changes to delivered software from
customers and developers, working out the costs and impact of making these changes, and deciding if
and when the changes should be implemented.

4. Release management This involves preparing software for external release and keeping track of the
system versions that have been released for customer use.

The development of a software product or custom software system takes place in

three distinct phases:
1. A development phase where the development team is responsible for managing the software
configuration and new functionality is being added to the software. The development team decides on
the changes to be made to the system.
2. A system testing phase where a version of the system is released internally for testing. This may be
the responsibility of a quality management team or an individual or group within the development
team. At this stage, no new functionality is added to the system. The changes made at this stage are bug
fixes, performance improvements, and security vulnerability repairs. There may be some customer
involvement as beta testers during this phase.
3. A release phase where the software is released to customers for use. After the release has been
distributed, customers may submit bug reports and change requests. New versions of the released
system may be developed to repair bugs and vulnerabilities and to include new features suggested by
customers.

Baseline
A collection of component versions that make up a system. Baselines are controlled, which means that
the component versions used in the baseline cannot be changed. It is always possible to re-create a
baseline from its constituent components.
Branching
The creation of a new codeline from a version in an existing codeline. The new codeline and the
existing codeline may then develop independently.
Codeline
A set of versions of a software component and other configuration items on which that component
depends.
Configuration (version) control
The process of ensuring that versions of systems and components are recorded and maintained so that
changes are managed and all versions of components are identified and stored for the lifetime of the
system.
Configuration item or software configuration item (SCI)
Anything associated with a software project (design, code, test data, document, etc.) that has been
placed under configuration control. Configuration items always have a unique identifier.
Mainline
A sequence of baselines representing different versions of a system.
Merging
The creation of a new version of a software component by merging separate versions in different
codelines. These codelines may have been created by a previous branch of one of the codelines
involved.

Release
A version of a system that has been released to customers (or other users in an organization) for use.
Repository
A shared database of versions of software components and metainformation about changes to these
components.
System building
The creation of an executable system version by compiling and linking the appropriate versions of the
components and libraries making up the system.
Version
An instance of a configuration item that differs, in some way, from other instances of that item.
Versions should always have a unique identifier.
Workspace
A private work area where software can be modified without affecting other developers who may be
using or modifying that software.

Version control (VC) systems identify, store, and control access to the different versions of
components. There are two types of modern version control system:
1. Centralized systems, where a single master repository maintains all versions of the software
components that are being developed. Subversion is a widely used example of a centralized VC system.
2. Distributed systems, where multiple versions of the component repository exist at the same time. Git
(Loeliger and McCullough 2012), is a widely used example of a distributed VC system.

Centralized and distributed VC systems provide comparable functionality but implement this
functionality in different ways. Key features of these systems include:

1. Version and release identification Managed versions of a component are assigned unique identifiers
when they are submitted to the system. These identifiers allow different versions of the same
component to be managed, without changing the component name. Versions may also be assigned
attributes, with the set of attributes used to uniquely identify each version.

2. Change history recording The VC system keeps records of the changes that have been made to
create a new version of a component from an earlier version. In some systems, these changes may be
used to select a particular system version. This involves tagging components with keywords describing
the changes made. You then use these tags to select the components to be included in a baseline.

3. Independent development Different developers may be working on the same component at the same
time. The version control system keeps track of components that have been checked out for editing and
ensures that changes made to a component by different developers do not interfere.

4. Project support A version control system may support the development of several projects, which
share components. It is usually possible to check in and check out all of the files associated with a
project rather than having to work with one file or directory at a time.

5. Storage management Rather than maintain separate copies of all versions of a component, the
version control system may use efficient mechanisms to ensure that duplicate copies of identical files
are not maintained. Where there are only small differences between files, the VC system may store
these differences rather than maintain multiple copies of files. A specific version may be automatically
re-created by applying the differences to a master version.

This model of development has a number of advantages: (Distributed version control system)
1. It provides a backup mechanism for the repository. If the repository is corrupted, work can continue
and the project repository can be restored from local copies.
2. It allows for offline working so that developers can commit changes if they do not have a network
connection.
3. Project support is the default way of working. Developers can compile and test the entire system on
their local machines and test the changes they have made.

Chapter9 Software evolution

Lehman’s law
Laws that involved when implement software evolution process
Maintenance to repair software faults 17%
Changing a system to correct deficiencies in the way meets its requirements.

Maintenance to adapt software to a different operating environment 18%

Changing a system so that it operates in a different environment (computer, OS, etc.) from its initial
implementation.

Maintenance to add to or modify the system’s functionality

Modifying the system to satisfy new requirements. 65%
Maintenance cost factors
Team stability
Maintenance costs are reduced if the same staff are involved with them for some time.

Contractual responsibility
The developers of a system may have no contractual responsibility for maintenance so there is no
incentive to design for future change.

Staff skills
Maintenance staff are often inexperienced and have limited domain knowledge.

Program age and structure

As programs age, their structure is degraded and they become harder to understand and change.

System quality and business value

- low quality, high business value
- low quality, low business value
- high quality , low business value
- high quality , high business value

Low quality, low business value

These systems should be scrapped.
Low-quality, high-business value
These make an important business contribution but are expensive to maintain. Should be re-
engineered or replaced if a suitable system is available.
High-quality, low-business value
Replace with COTS, scrap completely or maintain.
High-quality, high business value
Continue in operation using normal system maintenance.

Chapter 10 Software re-engineering

When need to re-engineering
When system changes are mostly confined to part of the system then re-engineer that part
When hardware or software support becomes obsolete
When tools to support re-structuring are available

Benefit of re-engineering
Reduced cost
- The cost of reengineering may be significantly less than the cost of developing new software. Ulrich
(1990) quotes an example of a commercial system for which the reimplementation costs were
estimated at $50 million. The system was successfully reengineered for $12 million. I suspect that, with
modern software technology, the relative cost of reimplementation is probably less than this but will
still considerably exceed the costs of reengineering.

Reduced risk
- There is a high risk in redeveloping business-critical software. Errors may be made in the system
specification or there may be development problems. Delays in introducing the new software may
mean that business is lost and extra costs are incurred.

Reengineerig process
Source code translation
- Using a translation tool, the program is converted from an old programming language to a more
modern version of the same language or to a different language.

Reverse engineering
- The program is analyzed and information extracted from it. This helps to document its organization
and functionality. Again, this process is usually completely automated.

Program structure improvement

- The control structure of the program is analyzed and modified to make it easier to read and
understand. This can be partially automated but some manual intervention is usually required.

Program modularization
- Related parts of the program are grouped together and, where appropriate, redundancy is removed. In
some cases, this stage may involve architectural refactoring (e.g., a system that uses several different
data stores may be refactored to use a single repository). This is a manual process.

Data reengineering
- The data processed by the program is changed to reflect program changes. This may mean redefining
database schemas and converting existing databases to the new structure. You should usually also clean
up the data. This involves finding and correcting mistakes, removing duplicate records, etc. Tools are
available to support data reengineering.

Chapter 11 Process improvement

What consider when introducing process improvement?

Size of the organization

Background and skills of the staff
Type of software being developed
Customer requirements
Market requirements
Organization culture
Aspects of the process to be improved - product related or process related or both

Factor affecting software product quality

Process quality
People quality
Cost, time and schedule
Development technology

These Software Quality Attributes in software engineering can be categorized under specific
areas as mentioned below:

#1) Design and Software Architecture Quality Attributes

 Conceptual Integrity
 Maintainability
 Reusability
 Correctness
#2) Runtime Qualities

 Reliability
 Interoperability
 Scalability (Flexibility)
 Performance
 Security
 Availability
#3) System Qualities

 Supportability
 Testability
#4) User Qualities

 Usability
#5) Non-runtime Qualities

 Portability
 Reusability

Reliability
Synonym for reliability is assurance. Reliability can be defined as the degree to which a software
system or its components or a service performs specific functions under predefined conditions for
a set period. It is the likelihood of fault-free software operation for a specified period of time in a
specified environment. A typical example is to have several servers in a cluster, so that if one of
the servers fails the other servers will continue processing seamlessly and take over the load of the
failed server. Another method could be to implement automatic failover.

Maintainability
It is the ease with which a software developer is able to fix flaws in the existing functionality
without impacting other components of the software system. It also considers the ease with which
a developer can add new features, update existing features or upgrade the system with new
technology.

Usability

This attribute refers to the quality of the end user’s experience while interacting with the application or
service. Usability is concerned with effectiveness, efficiency, and overall user satisfaction.This
attribute helps to measure the ease of use of any software application or service (e.g., registering a new
account and then signing in to the account) A web application for scientists and research students
had all of the necessary features, however, some of the sub-menus on one or more pages were
concealed (for instance, they were only seen after clicking the ellipsis button). As a result, users
had a tough time understanding how to start using those features.

Portability
It refers to the extent to which a system or its components can be migrated (transported) to other
environments consisting of different hardware and/or different software (operating system).
The importance of software portability should not be underestimated. Mobile version of event
booking software was working fine on Android but had issues with context menus on iOS.

Correctness
This refers to the ability of software products or services to perform tasks (e.g. calculations, sign-
ups, navigations) correctly as specified by the predefined requirements when used under specified
conditions.. It is a measure of whether a software system is correct or not, implying that it is an
all-or-nothing attribute. An online examination system had a remote proctoring feature. As per the
specification, it was required to have the option to enable/disable this functionality as required and
to work on all current browser versions. But in the production environment, the admin user
couldn’t disable this functionality on Firefox.

Efficiency

It is one of the most important software quality attributes. It reveals the performance of a software product
concerning the number of resources utilized under predefined conditions. It is measured simply in terms of the
time required by the software system or service to complete any given task. A survey application was collecting
data, which could be downloaded as an MS Excel file. However, the applications started freezing with
approximately 5000 records.

Security
It is defined as the capacity of a system to fend off or thwart malicious or unauthorized attempts to intrude and
damage it while still allowing access to authorized users. Additionally, it also measures the ability of the software
system to safeguard data and information from unauthorized entities.. As in recent years, the number of cyber-
attacks are on the rise, security of a software system should be given very high priority. One of the APIs of a large
customized survey application was accessible without proper authentication. Although only technically skilled
individuals could have utilized that API, it posed a significant security risk.

Supportability

It is the degree to which a software application can provide practically useful information helpful for identifying
and resolving issues when the application fails to work correctly.PDF downloads for resource booking applications
started failing in the production environment (which was working perfectly fine on test & release environments).
The lack of sufficient and appropriate error logging information caused a delay in providing the fix for it.

Aspects of process analysis

 Adoption and standardization

 Software engineering practice
 Organizational constraints
 Communication
 Tool support
 Introspection
 Learning

Capability maturity model (CMM)

 Initial
 Repeatable
 Defined
 Managed
 Optimising
Chapter 12 Software reuse

Actually in software engineering, system are compose by use existing components from other
existing system.

Benefit of software reuse

Increased dependability
Reduced process risk
Effective use of specialist
Standards compliance
Accelerated development

Reuse landscape
Application framework
- Collections of abstract and concrete classes are adapted and extended to create application
systems.
Software product line

COTS product reuse

ERP systems

Various types of specialization of a software product line may be developed:

1.
Platform specialization Versions of the application are developed for different platforms. For example,
versions of the application may exist for Windows, Mac OS, and Linux platforms. In this case, the
functionality of the application is normally unchanged; only those components that interface with the
hardware and operating system are modified.
2.
Environment specialization Versions of the application are created to handle particular operating
environments and peripheral devices. For example, a system for the emergency services may exist in
different versions, depending on the vehicle communications system. In this case, the system
components are changed to reflect the functionality of the communications equipment used.
3.
Functional specialization Versions of the application are created for specific customers who have
different requirements. For example, a library automation system may be modified depending on
whether it is used in a public library, a reference library, or a university library. In this case,
components that implement functionality may be modified and new components added to the system.
4.
Process specialization The system is adapted to cope with specific business processes. For example, an
ordering system may be adapted to cope with a centralized ordering process in one company and a
distributed process in another.

COTS-solution COTS-integrated systems

systems
Single product t Several heterogeneous system products are integrated to provide
hat provides the
functionality req customized functionality
uired by a custo
mer
Based around a Flexible solutions may be developed for customer processes
generic solution
and standardize
d processes
Development fo Development focus is on system integration
cus is on syste
m configuration
System vendor i System owner is responsible for maintenance
 s responsible fo
r maintenance
System vendor System owner provides the platform for the system
provides the pla
tform for the sys
tem

COTS integration problem

Lack of control over functionality and performance
COTS systems may be less effective than they appear
Problems with COTS system inter-operability
Different COTS systems may make different assumptions that means integration is difficult
No control over system evolution
COTS vendors not system users control evolution
Support from COTS vendors
COTS vendors may not offer support over the lifetime of the product