Software Engineering

• Computer Programs and associated documentation.

• Software products may be developed for a particular customer or may developed for a
general market.

What are the attributes of good software?

Good software should deliver the functionality and performance that the software users need
and should be maintainable, dependable, and usable.

What is software engineering?

Software engineering is an engineering discipline that is concerned with all aspects of
software production. “Engineering” means that systematic and managed approaches are used
for software development.

Fundamental software engineering activities:

 Software specification
 software development
 software validation
 software evolution

What is the difference between software engineering and computer science?

Computer science focuses on theory and fundamentals; software engineering is concerned

with the practicalities of developing and delivering useful software.

What is the difference between software engineering and system engineering?

System engineering is concerned with all aspects of computer-based systems development

including hardware, software and process engineering. Software engineering is part of this
more general process.

What are the key challenges facing software engineering?

1. Coping with increasing diversity

2. Demands for reduced delivery times
3. Developing trustworthy software

What are the costs of software engineering?

Roughly 60% of software costs are development costs, 40% are testing costs. For custom
software, evolution costs often exceed development costs.

Agile software development

Agile software development is a modern and iterative approach to software development that
prioritizes flexibility, collaboration, customer involvement, and incremental delivery of
working software. Agile methodologies, such as Scrum, Kanban, and Agile/Lean, are widely
used in software development projects to respond to changing requirements, improve team
productivity, and deliver high-quality software.

Key practices in agile software development include:

 Iterative development: Agile teams work in short, time-boxed iterations or sprints,

typically lasting one to four weeks, and deliver working software at the end of each
iteration.

 Cross-functional teams: Agile teams are typically composed of members with diverse
skills, such as developers, testers, designers, and business representatives, who work
collaboratively to deliver software.

 Continuous integration and testing: Agile teams continuously integrate code changes
and conduct automated testing to ensure that the software is always in a releasable
state and of high quality.

 Product backlog and prioritization: Agile teams maintain a prioritized list of

requirements or features, known as a product backlog, and work on the most valuable
items first, based on customer feedback and priorities.

 Daily stand-up meetings: Agile teams typically hold short, daily stand-up meetings to
synchronize work, identify and address obstacles, and plan the day's work.

 Retrospectives: Agile teams conduct regular retrospectives to reflect on the team's

performance, identify areas for improvement, and implement changes to optimize the
development process.

 Visual management: Agile teams often use visual management techniques, such as
Kanban boards or task boards, to provide transparency and visibility into the status of
work items and progress.

Requirement engineering

It’s the process of eliciting, documenting, validating, and managing the needs, expectations,
and constraints of stakeholders for a software system or solution. It involves understanding
and defining the desired functionalities, performance, and characteristics of the system to be
developed or enhanced. Requirement engineering is a critical phase in the software
development lifecycle, as it lays the foundation for the successful development of a software
system that meets the needs of its intended users. The process includes activities such as
stakeholder identification, requirements gathering, documentation, prioritization, validation,
and management to ensure that the software system is built to satisfy the identified
requirements and deliver value to stakeholders.
Software engineering ethics

 Software engineering involves wider responsibilities than simply the application of

technical skills.
 Software engineers must behave in an honest and ethically responsible way if they are to
be respected as professionals.
 Ethical behaviour is more than simply upholding the law but involves following a set of
principles that are morally correct.

Issues of professional responsibility

 Confidentiality - Engineers should normally respect the confidentiality of their employers

or clients irrespective of whether or not a formal confidentiality agreement has been signed.

 Competence - Engineers should not misrepresent their level of competence. They should
not knowingly accept work which is outwith their competence.

 Intellectual property rights - Engineers should be aware of local laws governing the use of
intellectual property such as patents, copyright, etc. They should be careful to ensure that the
intellectual property of employers and clients is protected.

 Computer misuse - Software engineers should not use their technical skills to misuse other
people’s computers. Computer misuse ranges from relatively trivial (game playing on an
employer’s machine, say) to extremely serious (dissemination of viruses).

Ethical 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.

What is a software process model?

A software process model is an abstract representation of a process. It presents a description

of a process from some particular perspective.
Many different software processes but all involve:
 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.

Activities in the software process

specifying a data model, designing a user interface, etc. and the ordering of these activities.

Difference between plan driven and agile processes

Plan-driven processes are processes where all of the process activities are planned in advance
and progress is measured against this plan.

In agile processes, planning is incremental and its easier to change the process to reflect
changing customer requirements.

In practice, most practical processes include elements of both plan-driven and agile
approaches.

Difference between waterfall and incremental processes

The main difference between waterfall and incremental processes lies in their approach to
software development and project management. The waterfall process is a sequential and
linear approach with detailed upfront planning and limited customer involvement, while the
incremental process is iterative and adaptive with continuous customer involvement and an
emphasis on early detection and mitigation of issues.

The waterfall model - Plan-driven model. Separate and distinct phases of specification
and development.

There are separate identified phases in the waterfall model:

 Requirements analysis and definition
 System and software design
 Implementation and unit testing
 Integration and system testing
 Operation and maintenance

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.

Inflexible partitioning of the project into distinct stages makes it difficult to respond to
changing customer requirements. Therefore, this model is only appropriate when the
requirements are well-understood and changes will be fairly limited during the
design process.
The need for Waterfall model

1. Embedded systems where the software has to interface with hardware systems.
2. Critical systems where there is a need for extensive safety and security analysis of the
software specification and design.
3. Large software systems that are part of broader engineering systems developed by
several partner companies. The hardware in the systems may be developed using a
similar model, and companies find it easier to use a common model for hardware and
software.

Incremental development - Specification, development and validation are interleaved.

Benefits

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.

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.

More rapid delivery and deployment of useful software to the customer is possible. -
Customers are able to use and gain value from the software earlier than is possible with a
waterfall process.

Problems

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.

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

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

In simple terms, reuse-oriented software engineering involves creating software components

that are designed to be modular, flexible, and generic, so they can be easily used and reused
in different software systems without having to be developed from scratch each time. These
reusable components can be libraries, frameworks, templates, or other types of software
artifacts that can be plugged into different applications or projects to provide common
functionality or solve common problems.
Process stages
 Component analysis;
 Requirements modification;
 System design with reuse;
 Development and integration.
 System validation

Software specification

The process of establishing what services are required and the constraints on the system’s
operation and development.

 Requirements engineering process

 Feasibility study
• Is it technically and financially feasible to build the system?
 Requirements elicitation and analysis
• What do the system stakeholders require or expect from the system?
 Requirements specification
• Defining the requirements in detail
 Requirements validation
• Checking the validity of the requirements

Software design and implementation

The process of converting the system specification into an

executable system.

 Software design - Design a software structure that realises the specification;

 Implementation- Translate this structure into an executable program;

The activities of design and implementation are closely related and may be inter-leaved.

Design activities

 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.
 Component design, where you take each system component and design how it will operate.
 Database design, where you design the system data structures and how these are to be
represented in a database.

Validation

 Verification and validation (V & V) is intended to show that a system conforms to its
specification and meets the requirements of the system customer.
 Involves checking and review processes and system testing.
 System testing involves executing the system with test cases that are derived from the
specification of the real data to be processed by the system.
 Testing is the most commonly used V & V activity.

Testing stages

Development or component testing

 Individual components are tested independently;
 Components may be functions or objects or coherent groupings
of these entities.

System testing
 Testing of the system as a whole. Testing of emergent properties
is particularly important.

Acceptance testing
 Testing with customer data to check that the system meets the customer’s needs.

System evolution

System evolution refers to the process of continuous change and improvement of a software
system or application over time. It involves modifications, enhancements, updates, and
maintenance activities that are performed on a system after it has been initially developed and
deployed.

Agile methodologies and incremental methodologies have some similarities in their iterative
and incremental approaches to software development. However, Agile methodologies tend to
be more flexible, customer-focused, and adaptable, with a greater emphasis on team
collaboration and shorter feedback loops, while incremental methodologies may involve
more upfront planning, documentation, and predefined phases. Both approaches can be
effective for system evolution depending on the specific needs and requirements of the
project.
Key differences:

1. Flexibility and adaptability: Agile > Incremental

2. Continuous customer involvement: Agile > Incremental
3. Documentation and planning: Incremental > Agile
4. Team collaboration and self-organization: Agile > Incremental
5. Frequency of delivery: Agile > Incremental