Unit 1

Professional Software Engineering:

Most software development is a professional activity aimed at creating
software for business, devices, or products.

Professional software is usually intended for use by others and developed

by teams.

Software engineering supports professional development, including

specification, design, and evolution.

Software includes not just programs but also documentation, libraries, and
configuration data.

Professional software systems often consist of multiple programs and

extensive documentation.

Key attributes of professional software include safety, responsiveness, and

reliability, depending on the application.

Software products are of two types

1. Generic Products: Stand-alone systems produced for sale on the open

market, such as apps, databases, and word processors.

2. Customized (Bespoke) Software: Systems developed specifically for a

particular customer, such as control systems for devices or business
process support systems.

Software Engineering
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:
Engineering Discipline

Engineers apply theories, methods, and tools selectively to solve problems,

even when existing theories are not available.

They work within organizational and financial constraints, finding solutions

that fit these limitations.

Unit 1 1
 All Aspects of Software Production

Software engineering involves more than just the technical processes of

development; it also includes project management.

It covers the development of tools, methods, and theories to support the

software development process.

Essential attributes of good software

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 methods leads to higher costs for testing, quality assurance,
and long-term maintenance.

Four fundamental activities are common to all software

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

2. Software development, where the software is designed and programmed.

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

4. Software evolution, where the software is modified to reflect changing

customer and market requirements.

General issues that affects Software:

1. Heterogeneity:

Modern systems must function as distributed systems across diverse

networks.

Software must operate on a range of devices, including computers, mobile

phones, and tablets.

Integration with legacy systems, often written in different programming

languages, is a common challenge.

The key challenge is developing dependable software that is flexible

enough to handle this heterogeneity.

2. Business and Social Change:

Businesses and society are rapidly evolving due to emerging economies

and new technologies.

There's a need for quick adaptation and development of new software to

meet changing demands.

Traditional software engineering methods may be too slow, causing delays

in delivering new systems.

Evolving software engineering techniques is crucial to reducing the time

needed for software to deliver value to customers.

3. Security and Trust:

As software becomes integral to daily life, ensuring its trustworthiness is

critical.

This is particularly important for remote systems accessed via web pages
or services.

Protecting against malicious attacks and maintaining information security

are vital concerns.

Unit 1 3
 4. Scale:

Software development must accommodate a wide range of scales, from

small embedded systems to large cloud-based systems.

Developing scalable solutions that can serve global communities is

increasingly important.

5.Software engineering diversity

Software engineering considers cost, schedule, dependability, and

customer/producer needs.

Methods, tools, and techniques vary by organization, software type, and

development team.

No single universal software engineering method exists; a diverse set has

evolved over 50 years.

The SEMAT initiative proposes a fundamental meta-process adaptable for

different software processes.

SEMAT is in early development and may improve current software

engineering methods.

There are many different types of application, including

1. Stand-alone Applications:

Run on personal computers or mobile devices.

Include all necessary functionality without requiring network connection.

Examples: Office applications, CAD programs, photo manipulation software,

productivity apps.

2. Interactive Transaction-Based Applications:

Execute on remote computers, accessed by users via their own devices.

Include web applications (e.g., e-commerce) and business systems

accessed through browsers or client programs.

Often incorporate a large data store that is accessed and updated with each
transaction.

3. Embedded Control Systems:

Software that controls and manages hardware devices.

Unit 1 4
 Most common type of system in terms of numbers.

Examples: Mobile phone software, antilock braking software in cars,

microwave oven control software.

4. Batch Processing Systems:

Designed to process data in large batches.

Process large numbers of inputs to create corresponding outputs.

Examples: Periodic billing systems, salary payment systems.

5. Entertainment Systems:

Intended for personal use and entertainment, mainly games.

May run on special-purpose console hardware.

Quality of user interaction is a key characteristic.

6. Systems for Modeling and Simulation:

Developed to model physical processes or situations involving many

interacting objects.

Often computationally intensive and require high-performance parallel

systems.

Used by scientists and engineers.

7. Data Collection and Analysis Systems:

Collect data from the environment and send it to other systems for
processing.

Interact with sensors, often in hostile environments like engines or remote

locations.

"Big data" analysis may involve cloud-based systems for statistical

analysis.

8. Systems of Systems:

Composed of multiple other software systems within large organizations.

May include generic software products (e.g., ERP systems) and custom
systems specific to the environment.

Software Engineering Fundamentals

Unit 1 5
 Internet software Engineering:
Initially, the web was primarily an information store with minimal impact on
local software systems.

Around 2000, web browsers evolved, enabling web-based systems to

replace special-purpose user interfaces.

This led to new system products and services accessible via the web, often
funded by ads instead of direct payments.

Business software shifted to web-based deployment on servers, reducing

costs and simplifying updates without needing installation on every PC.

The rise of Software as a Service (SaaS) and cloud computing has become
the standard, with software running on remote clouds and accessed over
the Internet.

Software Engineering Ethics

Key Ethical Considerations in Software Engineering:
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 processes

Unit 1 6
 A software process is a set of related activities that leads to the production of
a software system

Topics to be covered(
SE ethics
Waterfall
Increment development
Integration and configuration
Software design implementation
Prototyping

Principles of ethics
Agile model
)

Agile

Agile Software Development

Introduction to Rapid Software Development
Businesses operate in a global, rapidly changing environment.

New software must be developed quickly to respond to opportunities and

competitive pressures.

Rapid development and delivery often outweigh software quality and

complete requirement satisfaction.

Challenges in Software Requirements

Difficult to derive stable and complete requirements in a dynamic business
environment.

Requirements often change due to:

Unpredictable user needs.

Interactions with other systems.

Evolving working practices.

External factors.

Unit 1 7
 True requirements often emerge only after system delivery and user
experience.

Plan-Driven Development
Relies on complete specification before design and implementation.

Suitable for stable requirements and safety-critical systems.

Drawbacks in fast-moving environments:

Lengthy processes with potential rework.

Software may become obsolete by delivery.

Need for Agile Development

Recognized need for handling changing requirements since the 1990s.

Agile methods emerged as a solution to produce software rapidly and

adaptively.

Examples of agile methods:

Extreme Programming (XP) – Beck, 1999.

Scrum – Schwaber and Beedle, 2001.

Dynamic Systems Development Method (DSDM) – Stapleton, 2003.

Characteristics of Agile Methods

1. Interleaved Processes:

Specification, design, and implementation occur together.

Minimal documentation; focus on essential system characteristics.

2. Incremental Development:

Developed in small increments with stakeholder involvement.

Stakeholders provide feedback and propose changes for subsequent

versions.

3. Extensive Tool Support:

Tools for automated testing, configuration management, system

integration, and user interface production.

4. Frequent Releases:

Unit 1 8
 New system releases every 2-3 weeks.

Encourages customer feedback and rapid adaptation.

Key Differences: Agile vs Plan-Driven Development

Plan-Driven:

Sequential stages with formal outputs.

Iteration within activities.

Formal documentation and processes.

Agile:

Continuous iteration across activities.

Minimal documentation; informal communication.

Requirements and design evolve together.

Practical Hybrid Approaches

Plan-driven processes can incorporate incremental development.

Agile processes may include planned activities like system modeling and
documentation.

Combining approaches allows flexibility while maintaining some structured

practices.

Unit 1 9
 Agile methods
Origins: Developed in the 1980s and early 1990s for large, long-lived
systems like aerospace and government projects.

Characteristics:

Emphasis on formal project planning, quality assurance, and rigorous

processes.

Suitable for geographically dispersed teams working on large, critical

systems.

Heavy overhead due to extensive planning, designing, and

documentation requirements.

Limitations:

High overhead makes it inefficient for small to medium-sized business

systems.

Changes in requirements demand significant rework, affecting cost and

timelines.

Focuses more on process than on actual software development and

testing.

Agile Methods
Development: Introduced in the late 1990s as a response to dissatisfaction
with heavyweight plan-driven processes.

Focus:

Prioritizes software delivery over documentation and bureaucratic

processes.

Accommodates rapidly changing requirements during development.

Delivers working software incrementally with customer feedback at

every stage.

Philosophy (Agile Manifesto Values):

Individuals and interactions over processes and tools.

Working software over comprehensive documentation.

Customer collaboration over contract negotiation.

Unit 1 10
 Responding to change over following a plan.

Principles of Agile Methods

1. Customer Involvement:

Customers provide and prioritize requirements and evaluate iterations

of the system.

2. Embrace Change:

Systems are designed to accommodate changing requirements

throughout the development process.

3. Incremental Delivery:

Software is delivered in increments, with requirements for each

increment specified by the customer.

4. Maintain Simplicity:

Focus on eliminating complexity in both the software and the

development process.

5. People Over Process:

Leverages the skills of the team, allowing members to define their own
workflows.

Application of Agile Methods

1. Product Development:

Suitable for small and medium-sized software products or apps for

commercial sale.

Agile is widely used in almost all modern software product

development.

2. Custom System Development:

Effective when the customer is committed to active involvement during

development.

Best for projects with minimal external stakeholders or regulatory

constraints.

Unit 1 11
 Key Advantages of Agile
Continuous communication between the customer and development team
ensures alignment.

Works well for stand-alone systems without complex integrations.

Informal communication supports co-located teams working on small to

medium-sized systems.

Agile Development Techniques

Extreme Programming (XP)
1. Introduction to XP

Origin: Coined by Kent Beck in the 1990s.

Core Idea: Pushes good practices (like iterative development) to extreme

levels.

Key Features:

Frequent new versions developed, integrated, and tested daily.

Requirements expressed as user stories and implemented as tasks.

Tests are created before code, and all tests must pass after integration.

Short release cycles.

Unit 1 12
 2. XP Practices
1. Incremental Development

Frequent small releases with functionality derived from user stories.

Focus on delivering business value with each increment.

2. Customer Involvement

On-site customer representative actively collaborates with the development

team.

Responsible for defining and validating acceptance tests.

3. People-Centric Development

Pair Programming: Developers work in pairs to review and improve each

other's work.

Collective Ownership: All developers share responsibility for the codebase.

Sustainable Pace: Avoids burnout with balanced workloads.

Unit 1 13
 4. Continuous Integration

Tasks are integrated into the main system immediately upon completion.

All unit tests must pass after every integration to ensure stability.

5. Test-First Development

Automated tests are written before implementing functionality.

Ensures code correctness and prevents regressions.

6. Refactoring

Continuous improvement of code structure without changing its behavior.

Keeps the codebase simple, clean, and maintainable.

7. Simple Design

Only the necessary design for current requirements is created.

Avoids over-engineering and anticipates changes flexibly.

8. Small Releases

Each release provides minimal but valuable functionality.

Frequent iterations add incremental features.

9. Sustainable Development

Balanced work hours to maintain long-term productivity and code quality.

3. Key Principles of XP

Embrace Change: Frequent releases, refactoring, and test-first

development make the system a+daptable.

Maintain Simplicity: Focus on simple designs and regular refactoring for

maintainable systems.

4. XP in Practice

XP practices are often adapted or integrated with methods like Scrum.

Companies pick practices based on suitability for their workflows and

management culture.

Example User Story: "Prescribing Medication"

Scenario: A doctor prescribes medication using a system.

Unit 1 14
 Steps:

Selects current, new, or formulary medication.

Enters or adjusts dosage.

Confirms prescription, which is recorded in the database.

If the dose is outside the approved range, a change is prompted.

User Stories
Introduction to User Stories

Purpose: Simplify requirements elicitation and adapt to changing

requirements during agile development.

Definition: A user story is a scenario describing how a system is used by a

user.

Format: Described briefly on a story card, encapsulating customer needs

and use cases.

2. Characteristics of User Stories

Customer Collaboration: Customers work closely with the development

team to develop story cards.

Iterative Development: Stories are implemented incrementally in system

iterations.

Brief and Flexible: Each story is short and can be modified or discarded as
requirements evolve.

3. Example of a User Story

Scenario: Prescribing medication in the Mentcare system.

Actions:

1. Select current medication, new medication, or formulary.

2. Adjust or confirm the dose.

3. System validates the dose and updates the patient record.

Story Card: Captures the entire process in a concise format.

4. Breaking Down User Stories

Unit 1 15
 Stories are broken into smaller tasks to simplify implementation.

Example Tasks for Prescribing Medication:

1. Change Dose of Prescribed Drug: Allow dose adjustments.

2. Formulary Selection: Retrieve drug information using the formulary.

3. Dose Checking: Validate dose against safety limits and enable

confirmation.

5. Benefits of User Stories

Ease of Understanding: More relatable than formal requirements

documents.

Customer Engagement: Encourages customer input and prioritization.

Rapid Delivery: Facilitates implementation of useful features in short

iterations (e.g., two weeks).

Flexibility: Supports evolving requirements and reprioritization.

6. Challenges of User Stories

Completeness:

Difficult to ensure all essential requirements are covered.

Some activities might be left out due to assumptions or oversight by

experienced users.

Accuracy:

A single story may not fully capture the complexity of an activity.

Evolving Nature: Stories change frequently, making long-term planning

harder.

7. Iterative Process with User Stories

1. Initial Creation: Collaboratively written by customers and developers.

2. Task Breakdown: Development team divides the story into smaller tasks for
implementation.

3. Prioritization: Customers decide the priority of stories for the next release.

4. Refinement: Stories are revised as requirements change.

Unit 1 16
 8. Key Takeaways

User stories are a user-friendly way to gather and prioritize requirements.

They are integral to agile development, ensuring flexibility and continuous

delivery.

Completeness and clarity require ongoing collaboration and refinement.

Refactoring
1. Design for Change:

Traditional software engineering emphasizes designing software with future

changes in mind.

The goal is to anticipate possible future requirements and create flexible

designs that allow easy modifications.

However, extreme programming (XP) challenges this idea, arguing that

adding unnecessary generality to the design can be a waste of effort.

In many cases, the anticipated changes do not materialize, or the nature of

the changes may differ significantly from what was expected.

2. The Need for Refactoring:

Despite the unpredictability of future changes, modifications to the code

are inevitable during the development process.

Refactoring (Fowler et al., 1999) refers to continuously improving the

software’s internal structure while maintaining its external behavior.

XP suggests constant refactoring, even when there’s no immediate need for

change, to keep the software maintainable.

Refactoring should be seen as an ongoing process, improving the

codebase incrementally.

3. Incremental Development and Software Degradation:

In incremental development, changes are often made to the existing code to

accommodate new requirements or fix issues.

This process can lead to software degradation:

Code duplication occurs.

Inappropriate reuse of code leads to inefficiencies.

Unit 1 17
 The overall structure deteriorates as workarounds are applied.

Over time, these changes make further development and maintenance

more difficult.

4. Benefits of Refactoring:

Refactoring helps to maintain a clean and understandable codebase.

It avoids the structural deterioration that results from continued ad-hoc

modifications.

Examples of refactoring include:

Reorganizing class hierarchies to eliminate duplicate code.

Tidying up and renaming methods and attributes for clarity.

Replacing similar code sections with calls to reusable methods from a

program library.

5. Refactoring Tools:

Most program development environments provide tools that assist with

refactoring.

These tools can:

Identify dependencies between code sections.

Make global code modifications with minimal risk of errors.

6. Challenges with Refactoring:

In theory, refactoring ensures the software remains easy to understand and

adaptable as new requirements emerge.

In practice, the pressure to deliver new features may cause refactoring to

be delayed.

Refactoring can sometimes be insufficient when significant architectural

changes are required to accommodate new functionality.

Test first development

1. Overview:

In XP, a key difference between incremental and plan-driven development

is the testing approach.

Unit 1 18
 XP integrates testing as a central part of development, with an emphasis on
automated tests that must pass before proceeding with the code.

Test-First Development is a core principle of XP and has evolved into Test-

Driven Development (TDD).

2. Test-First Development:

In Test-First Development, tests are written before the actual code.

This approach defines both the interface and behavior of the functionality
being developed.

By writing tests first, ambiguities and misunderstandings in requirements

are identified early, reducing the risk of misalignment with customer needs.

Problems like test-lag, where developers move faster than testers and skip
tests, are avoided.

3. Key Features of XP Testing:

Test-First Development: Writing tests before the code.

Incremental Test Development from Scenarios: Building tests based on

real-world scenarios.

User Involvement in Test Development: Customers collaborate in defining

and validating tests.

Automated Testing Frameworks: Tests are automated to ensure fast

execution and feedback.

4. Advantages of Test-First Development:

Clarification of Requirements: Writing tests requires a thorough

understanding of the specification, ensuring that ambiguities are resolved
before implementation starts.

Continuous Feedback: Tests are run frequently to catch issues as new

code is written, allowing for quicker identification of problems.

Reduced Misunderstandings: The development process aligns closely with

the actual user needs through direct collaboration on test creation.

5. Writing Tests:

Tests are defined before code implementation to serve as the specification

of behavior.

Unit 1 19
 Automated Tests: Tests should be executable, stand-alone, simulate
inputs, and check the output against expected results.

Unit Tests: Each task in the development process generates one or more
unit tests, which ensure the functionality is correctly implemented.

6. Customer Role in Testing:

The customer works alongside the development team to define acceptance

tests for user stories to validate if the system meets the real needs.

Acceptance testing involves using real customer data to ensure the

software performs as expected.

7. Automated Testing Frameworks:

Automation tools like JUnit for Java are used to write and run tests easily.

The automated framework ensures tests can be run quickly, providing

immediate feedback to detect problems introduced by new functionality.

8. Challenges in Test-First Development:

Incomplete Tests: Sometimes developers take shortcuts and write

incomplete tests, leaving some edge cases or exceptions untested.

Difficult-to-Write Tests: Complex parts of the system, such as user

interfaces, may be challenging to test incrementally.

Test Coverage Completeness: Even with numerous tests, it's difficult to

ensure full test coverage. Some parts of the system may remain untested,
leading to undetected bugs.

9. Potential Issues in Test-First Development:

The large number of tests generated can create a false sense of

completeness. If tests are not reviewed or new tests are not added after
development, undetected bugs could remain in the final product.

Test completeness may be difficult to judge, especially if crucial parts of

the system are not tested due to the challenges in writing comprehensive
tests.

Pair Programming
1. Overview:

Unit 1 20
 Pair programming is an innovative practice introduced in Extreme
Programming (XP) where two programmers work together at the same
computer to develop software.

Pairs are not fixed and are created dynamically, so each team member
collaborates with others throughout the development process.

2. Advantages of Pair Programming:

Collective Ownership and Responsibility:

Pair programming supports the idea that the team collectively owns and
is responsible for the software.

This reflects the concept of egoless programming (Weinberg, 1971),

where no individual is solely responsible for issues in the code. Instead,
the whole team shares responsibility for problem resolution.

Informal Review Process:

Pair programming acts as a continuous informal review process, where

each line of code is reviewed by at least two people.

Although formal code inspections and reviews are effective in detecting

errors, they are time-consuming and can delay development.

Pair programming, while less formal, is cheaper and easier to organize

and still catches a significant number of errors.

Encourages Refactoring:

Pair programming encourages refactoring, improving the software’s

structure. Refactoring often requires effort for long-term benefit, which
can be seen as less efficient in a traditional development environment.

In pair programming, others immediately benefit from the refactoring,

fostering support for the process.

3. Efficiency Considerations:

A common concern is that pair programming might be less efficient than

individual programming because a pair would produce half as much code
as two individuals working separately.

Some companies are skeptical of pair programming and mix it with

individual programming, often pairing an experienced programmer with a
less experienced one.

Unit 1 21
 4. Studies on Pair Programming:

Studies with Student Volunteers (Williams et al., 2000):

In studies involving student volunteers, pair programming was found to

be comparable in productivity to that of two independent programmers.

This is because pairs discuss the software before development, leading

to fewer false starts and less rework.

The informal inspection process also helps avoid errors that would
otherwise be discovered later in the testing phase, reducing time spent
on bug fixing.

Studies with Experienced Programmers (Arisholm et al., 2007):

Research involving more experienced programmers showed a

significant loss of productivity with pair programming compared to
working independently.

Although there were some quality benefits, the productivity loss did
not fully justify the pair-programming overhead.

5. Knowledge Sharing:

A key benefit of pair programming is the sharing of knowledge between

team members.

This reduces overall risks to the project, particularly when team members
leave, as the knowledge is distributed across the team.

Unit 1 22