SOFTWARE CONSTRUCTION

SE3318

Ali Mert Ceylan

SPRING 2024-2025
MEASURE TWICE, CUT ONCE
PREREQUISITES OVERVIEW

Importance of Prerequisites
Problem-Definition Prerequisite
Determine the Kind of So!ware
Requirements Prerequisite
Architecture Prerequisite
IMPORTANCE OF PREREQUISITES

Plan a project
Create a business case
Develop comprehensive and accurate requirements
Design high-quality architectures
WHAT TO DO TO NOT START WITHOUT PREREQUISITES?

1. Refuse to do work in an ineffective order.

2. Pretend to be coding when you're not.
3. Educate your boss in the technical nuances.
WHY SHOULD WE DO PREREQUISITES BEFORE CONSTRUCTION?

Appeal to logic
Appeal to analogy
Appeal to data
APPEAL TO DATA
BOSS READINESS

"We’d better start coding right away because we’re going to have a
lot of debugging to do."
"We haven’t planned much time for testing because we’re not going
to find many defects."
"We’ve investigated requirements and design so much that I can’t
think of any"
PROBLEM-DEFINITION PREREQUISITE
PROBLEM-DEFINITION PREREQUISITE
POP QUIZ: PROBLEM DEFINITION

We can’t keep up with orders for the Gigatron

Is this a problem definition?

POP ANSWER: PROBLEM DEFINITION

We can’t keep up with orders for the Gigatron

Yes, it states a problem.

POP QUIZ: PROBLEM DEFINITION

We need to optimize our automated data-entry

system to keep up with orders for the Gigatron.

Is this a problem definition?

POP ANSWER: PROBLEM DEFINITION

We need to optimize our automated data-entry

system to keep up with orders for the Gigatron.

No, it states a solution.

POP QUIZ: PROBLEM DEFINITION

Our current so!ware system is not compatible with

our new hardware upgrades, leading to technical
issues and delays in project completion.

Is this a problem definition?

POP QUIZ: PROBLEM DEFINITION

Our current so!ware system is not compatible with

our new hardware upgrades, leading to technical
issues and delays in project completion.

Yes, it states a problem.

ITERATIVE APPROACHES AND PREREQUISITES
ITERATIVE APPROACHES AND PREREQUISITES
WHAT KIND OF SOFTWARE YOU'RE WORKING ON?
EVOLUTIONARY DELIVERY
Time Segments

Software Concept

Preliminary Requirement Analysis

Design of Architecture and

System Core

Develop a Version

Deliver the Version

Elicit Customer Feedback

Incorporate Customer Feedback

Develop Deliver Elicit Incorporate

EVOLUTIONARY DELIVERY

Reduces the risk of delivering a product that the customer doesn't

want.
It makes progress visible.
Supports more frequent product releases.
Reduces estimation error by allowing for recalibration and re-
estimation.
Reduces the risk of integration problems by integrating early.
Improves morale.
POP QUIZ: ITERATIVE APPROACHES

Which so!ware development process metaphor is the most similar to

Evolutionary Delivery?
POP ANSWER: ITERATIVE APPROACHES

System Accretion
STAGED DELIVERY
Temporal Segments

Alpha Beta RC

Software Concept

Requirement Analysis

Architectural Design

Detailed Design

Code, Debug

Test

Delivery

Design Code&Deb Test Delivery

ug
STAGED DELIVERY

Plan each delivery stage using Miniature Milestones.

Success depends on defining a family of programs.
Less flexible than Evolutionary Delivery
Trades increased planning effort for increased progress visibility
Pop Quiz: Staged Delivery

Why success depends on defining a family of programs?

Pop Answer: Staged Delivery

Ecosystem Integration: Features are part of the system that

functions together.
UX Improvement: Features are updated together and maintains
consistency.
Scalability and Flexibility: Easier to extend a functionality more
flexibly.
Quality Assurance: Set of features tested together to test a function.
Pop Quiz: Staged Delivery

What is the most obvious example for Staged Delivery life cycle model?
Pop Answer: Staged Delivery

What is the most obvious so!ware example for Staged Delivery life cycle
model?
SPIRAL DELIVERY
SPIRAL DELIVERY

One of the most important advantages of the spiral model is that as

costs increase, risks decrease.
Since model is risk oriented, you have the checkpoints at the end of
each iteration.
Complicated model, requires conscientious, attentive, and
knowledgeable management.
REQUIREMENTS PREREQUISITE
REQUIREMENTS PREREQUISITE

Why Have Official Requirements?

The user can review them and agree to them.
Paying attention to requirements helps to minimize changes to
a system a!er development begins.
HANDLING REQUIREMENTS CHANGES DURING CONSTRUCTION

Use the requirements checklist

Make sure everyone knows the cost of requirements changes
Set up a change-control procedure
Use development approaches that accommodate changes
Keep your eye on the business case for the project

or dump the project and start over

SPECIFIC FUNCTIONAL REQUIREMENTS

Are all the inputs to the system specified, including their source,
accuracy, range of values, and frequency?
Are all the outputs from the system specified, including their
destination, accuracy, range of values, frequency, and format?
Are all the external communication interfaces specified, including
handshaking, error-checking, and communication protocols?
Are all the tasks the user wants to perform specified?
Is the data used in each task and the data resulting from each task
specified?
SPECIFIC NONFUNCTIONAL (QUALITY) REQUIREMENTS

Is the expected response time, from the user’s point of view,

specified?
Are other timing considerations specified?
Is the level of security specified?
Is the reliability specified and the strategy for error detection and
recovery?
Is the maintainability of the system specified?
Is the definition of success included? Of failure?
ARCHITECTURE PREREQUISITE
ARCHITECTURE PREREQUISITE

A well-thought-out architecture provides the structure to maintain,

conceptual integrity from the top levels down to the bottom

provides guidance to programmers—at a level of detail appropriate
to the skills of the programmers and to the job at hand
partitions the work so that multiple developers or multiple
development teams can work independently
ARCHITECTURE PREREQUISITE

Independent of frameworks. System shouldn't be limited by the

constraints imposed by the framework.
Testable. Business rules can be tested without UI, database, web
server, or external dependencies.
Independent of the UI. Type or look of UI should not affect the
business rules.
Independent of the database. Business rules should not be bound
to a specific database technology.
Independent of any external agency. Business rules should not
depend on any interfaces to outside world.
ARCHITECTURE PREREQUISITE
ARCHITECTURE PREREQUISITE

Entities. Entities are the business objects of the application.

Use cases. Orchestrate the flow of data to and from the entities,
and direct those entities to use their Critical Business Rules.
Interface Adapters. Convert data to the data format most
convenient for the use cases and entities.
Frameworks and Drivers. The web is a detail. The database is a
detail. Details should be kept outside where they can do little harm.
ARCHITECTURE PREREQUISITE

As you move inward, the level of abstraction and policy increases.

So!ware grows more abstract and encapsulates higher-level
policies.
ARCHITECTURE PREREQUISITE
KEY CONSTRUCTION DECISIONS
CHOICE OF PROGRAMMING LANGUAGE

By relieving the brain of all unnecessary work, a

good notation sets it free to concentrate on more
advanced problems, and in effect increases the
mental power of the race —Alfred North Whitehead
PROGRAMMING CONVENTIONS

Linter rules
Coding conventions
Design patterns
Writing specifications
Developer testing
YOUR LOCATION ON THE TECHNOLOGY WAVE

Project requirements and goals.

Company toolset and team expertise.
Ecosystem and community.
Interoperability.
Security considerations.
MAJOR CONSTRUCTION PRACTICES
MAJOR CONSTRUCTION PRACTICES: CODING

How much design will be done up front. (Requirements policy)

Conventions for names, comments and so!ware elements. (Coding
policy)
What coding practices implied by the technology or architecture.
(Construction policy)
How error conditions will be handled. (Error handling policy)
How security will be addressed. (Security policy)
MAJOR CONSTRUCTION PRACTICES: TOOLS

Environment management.
Dependency management
Language version, compiler version.
Framework choice and version.
A version control tool.
Coding standards
Policy on non-standard language features.
Editor, linter, debugger, test framework.
TOOLS : ENVIRONMENT/CONFIGURATION MANAGEMENT

Development
Chocolatey
Homebrew
Aptitude
Deployment
Ansible
Docker
LXC
TOOLS : DEPENDENCY MANAGEMENT

Java: Maven
Python: pyenv+virtualenv, Pipenv
Javascript: npm
TOOLS : VERSION CONTROL

Subversion svn
Contributors must be connected to repository server.
Centralized; Single repository server
Trunk-based development Contributors create branches.
Git git
Operates locally; contributors work on clones of the main
repository.
Distributed; copies distributed to clones, less risk of failure on
main repository.
Merge and Conflict resolution; changes easier to integrate.
MAJOR CONSTRUCTION PRACTICES: TEAMWORK

Development framework
Code review tasks
Sprint Review
Retrospective
Version control and integration workflow
Branch restrictions
Integration rules
Pull Request rules
TEAMWORK : CODE REVIEW : ADVANTAGES

Share knowledge: Code reviews help junior developers learn from

more senior team members.
Discover bugs earlier: Find and fix problems before customers ever
see them.
Maintain compliance: Help everyone adhere to the same standards.
Enhance security: Help detect security issues and ensure
compliance
Increase collaboration: Team members work together to create a
solution.
Improve code quality: A human who knows your code base can
notice code quality issues.
TEAMWORK : CODE REVIEW : DISADVANTAGES

Longer time to ship: Code reviews help junior developers learn from
more senior team members.
Pull focus from other tasks: A code review can pull their focus away
from other high priority tasks
Large reviews mean longer review times: Large code reviews are
challenging to assess.
TEAMWORK : SPRINT REVIEW

Team presents the results of their work to key stakeholders.

Progress toward the Product Goal is discussed.
Inspect the outcomes of the Sprint and determine future
adaptations.
TEAMWORK : RETROSPECTIVE
TEAMWORK : RETROSPECTIVE

What went well? Section that all team members write cards about
things went well.
What can be improved? Section that cards about things didn't go
smoothly during sprint.
Action points derived: Cards are voted and action points derived
from points to be improved and stories written and assigned to
responsible team members.
TEAMWORK : DEVELOPMENT FRAMEWORK : SCRUM

Day 1 Day 2 Day 3 Day 4 Day 5 Day 6 Day 7 Day 8 Day 9 Day 10

Standup Standup Standup Standup Standup Standup Standup Standup Standup Standup

Sprint
Review

Tricks and Retrospecti

Tricks and ve
Issues
Issues

Technical Technical Spring

Review Review Planning
TEAMWORK : VC AND INTEGRATION : ENVIRONMENT BASED
Integration
Tech Lead Team Lead Developer Server

Determine
Sprint
Goals Write
Set Sprint Goals
Stories
for Sprint
Goals Assign Developer to Story
Fork a
Branch
from DEV

Formalize
Specificat
ions

Develop
Feature

Develop
Smoke
Tests Create Pull Request
to DEV Static
Code
Analysis

Development Procedure
Merge
Conflicts
with DEV

Merge
into DEV

Run Unit
Tests

Plan Code
Reviews
Assign Reviewer

Send Notification
Review
Request
Review Vote

Send Notification
Review
Request
Review Vote
LABORATORY : THIS WEEK ON LAB

Tools will be introduced.

IDE
maven
Other setup and configurations
 End of Week 2

Thanks for listening