January 14, 2015

1968: Birth of Software Engineering

NATO: For military software, it wasn't till 80s for consumer sof
tware
But poor standard where you get blue screen of date
They thought by 80 they were teaching good software engineering
practices
But in 90s Internet software arrives, which is a new type of sof
tware - completely different software
Became extreme once more, poor quality and security vulnerabilit
ies
Then in Late 90s and 2000s, new processes -> Agile development w
hich led to new methodologies and paradigms
Relative distribution of software/hardware costs SLIDE!
Hardware became cheap and a commoditity
Barry Boehm predicted that in hindsight
------------------------------------------------------------------------------------------------------Software engineering (definition): the application of a systematic disci
plined, quantifiable approach to the development, operation and maintenanace of
software;
Systematic: dont according to a fixed plan or system
Disciplined: controlled form of behavior
Quantifiable: express or measure the key effects, how do we get
metrics - rigorous metrics for process
Development: design and building code
Operation: user interface and interaction with humans
Maintenance: users find bugs or they find something that you did
n't finish, therefore you work on it
Software Engineering Activities
Project planning - discipline and planning ahead
Cost estimation - need to know how much project will cost resour
ces (programmers), equipment and time
Requirements - have to do this, this and this
Elicitation - Extracting the requirements from the clien
t, what do you want, how do you want it to be done, and what do you want from it
Specification - after getting requimrenets from client,
how to write it down in clear that programmer, tester and client understands; it
'll be a contract
Design
High-level - client server architecture, layer approach
of libraries, high-level decisions about software
Detailed - what classes are we going to use, what interf
aces offered
Implementation
Testing
Verification - built software correctly (no null ptr)
Validation - did you build the right software, did you i
mplement the software correctly of the customer's want
Maintenance
Corrective - bug has been found, crash has been found, g
otta fix
Evolutionary - adding new features and adapting to new p
ieces of equipment
-> Trying to fix huge program with thousands of programmers

------------------------------------------------------------------------------------------------------Now, teams scattered around globe, components acquired from others, open
source parts, services found on Web while before everyone under one head progra
mmer in one place
SE Central Themes: big programs, complexity of thousands of little detai
l to be taken care of, software evolution (software is long lived), development
must be efficient, done by a team, software effectively support users, involves
different disciplines (biology, chemistry, domain-specific information)
Software Development Lifecycle: process by which the creation of softwar
e is managed, from inception to retirement; aka (software lifecycle, software de
v process, [variations])
Goals of a process
Repeatable - you can do at least as well as in the previous time
(for process)
Estimatable - how long it'll take to develop the project and how
much it'll cost
------------------------------------------------------------------------------------------------------Lifecycle Terminology
Phase: a grouping of conceptually related activities in software
lifecycle (implementation, compiling, unit tests)
Milestones: discrete events during lifecycle signalling achievem
ents (req doc created, requirement doc signed off, agreed by developer, unit tes
ts for each fx completed - yes or no)
Artifact: something that is generated by the development process
(any tangible output)
Deliverable: type of artifact that is deliverable to the client
80s Waterfall Method
Traditional way to conceptualize the baseline lifecycle that was
initial software lifecycle model
WATERFALL MODEL SLIDE: each box is a phase, arrows means moving
to next phase, V&V=verification and validation
Document driven, planning driven, heavyweight (takes a lot of ti
me sticking to process); planning upfront which heavy contracts are signed, we k
now we reached different milestones in this model
Problems with Waterfall Method
Heavy process - lots of paperwork and management oversight, can'
t make much changes in documentation or errors - there's no going back in the do
cument easily
------------------------------------------------------------------------------------------------------Phase: Project Management is concerned and ensuring that software is del
ivered on time, within budget and accordance with requirements; we need this bec
ause there are budgets and constraints; hard because budget and constraints are
imposed on you by external
Phase: Requirements yields a description of the desired systems, or the
functions, possible extensions, required documentations (user manuals), performa

nce requimrents and feasibility study (what are the big risks, is something diff
icult to implement) -> requirement specification document; in court this becomes
a contract and holds a legal status; stakeholder is EVERYONE using the process
Phase: Design in its earliest decision is captured in software architect
ure; then breaking high-level pieces (decomposition) into parts and components > design specification document in UML diagrams; it's intertwined with requireme
nts (twin peaks model)
Phase: Implementation is focused on individual components - goal is work
ing flexible robust software not bag of tricks; present-day languages have modul
es or class concepts (C++ / Java)
Phase: Testing is answering whether software is doing what its supposed
to do; are we building the right system (validation), testing happens on day 1,
which his built in
Phase: Maintenance is correcting errors found after software delivered a
nd adapting the software
------------------------------------------------------------------------------------------------------Distribution of Effort Per Phase (in man hours):
Most Expensive: Maintenance because the life time is in years, m
uch larger than building the software, low level over years is much more than bu
ilding the software product (50%)
Second most Expensive: Testing (45%), thinking about the code an
d what is the correct reponse when I give it the correct input, when should I ge
t a failure?
There after: Coding, Design, Requirements, Specification
Rule of thumb: 40-20-40 distrubtion of effort (design, coding, t
esting)
Concerning trend: enlarge requirements specification/design slot
s; reduce test slot
------------------------------------------------------------------------------------------------------Software Ethics
Manager wants to ship without testing, what do you do? (when lif
e can be at risk)
------------------------------------------------------------------------------------------------------Summary:
Definition of software engineering
Themes and concerns of SE
Lifecycle activities
Waterfall model
Distribution efforts
Ethical principles
================================================================================
=============================

January 21, 2015

Requirement: Key Issues
What will be built? - Describe software product delievered to customers
How do we communicate this? - Everyone works independently using softwar
e development sheet
Challenging because imprecise wording on technical terms, requirements c
hange
Requirement Phase:
Description of desired system (functions, required documentation - user
manual, performance requirements - approximation algorithm)
Feasibility study - is it possible to build?
The resulting documention as a result is called SRS - software requireme
nts specification
Requirement (definition):
A condition of capability needed by a user to solve a problem or achieve
an objective;
a condition or capability that must be met or possessed by a system...to
satisafy a contract, standard, specification or other formally imposed document
s
Software Requirements Specification (definition):
Document that describes what the software should do
Stakeholder (definition): an entity with an interest/concern in the software, en
d user, software developer, anyone who might have an interest in the end result
Requirement (unofficial definition): statement describing a service that a softw
are system should provide or the level of quality of a service
Can be high-level abstract statement of service or system constraint
Can be detailed mathematical functional specification
Three types of requirements:
1. Functional: concrete statements of what the system do, system must do
x with y and do z; you can write this as mathematical function
E.g. "The user shall be able to search either all of the initial
set of databases or select a subset from it."
Which user? How big is database, subset?
E.g. "The system shall provide appropriate viewers for the user
to read doucments in the document store."
What is appropriate?
E.g. "Every order shall be allocated a unique identifier (ORDER_
ID) which the user shall be able to copy to the account's permanent storage area
."
-???2. Non-functional: usability, systems such as timing constraint, constra
int on development process, standards; e.g. access
CHECK PICTURE ~21:40 AUDIO
External requirements: constraints by supplier systems, etc.
Ethical requirements: what is right level of testing?
Product requirements: "4.C.8 It shall be possible for all necess
ary communcation between APSE and the user to expressed in the standard Ada char
acter set"
External requirement: "The system shall not disclose any persona
l info about cusomters besides name and reference numbers"
3. Domain: requirements coming from application domain itself; for book
store, what does it mean to checkout book, how many books can be checked out, du
e date
Understandability - requirements are expressed in language of ap

plication domain, this is often not understood by software engineers

Implicitness - domain specialistic understand the area so well t
hat they do not think of making domain requirements explicit
Requirements Process
1. feasbility study - 30:14
first time: what is possible, what has other people done?
Decides whether a system is possible to implement or worthwhile
Does the system meet the goals the customer has given me? Can it
be built with current tech and budget? Can it be integrated with other systems
already in existance
2. understanding the problem: elictation
what are they trying to solve?
involves technical staff - find out about application domain, se
rvices that the system should provide, syetems's operational constraints
may include people overseeing, software engineers, domain expert
s, trade union, end-users, management
elicitation techniques: classic interview, Delphi techniques, br
ainstorming session, task analyis scenario analysis, ethnography (physically put
in environment and learn on experience)
1. UNDERSTAND STAKEHOLDERS NEEDS
2. IDENTIFY ALL STAKEHOLDERS ~39:13 AUDIO
Problems: stakeholders don't really know what they want, conflic
ting requimrents by diff stakeholders, organisation and political factors can in
fluence requirements, requirements change
Humans: different backgrouns, short/long term memory, human prej
udices (natural assumption on how things work), limited capability for rational
thinking
3. agreeing upon the boundaries of the problem: negotation
program might be huge project, negotiating pricing and time
4. describing the solution: specification
writing down the specfication
5. agreeing upon the nature of the problem: validation
Conceptual modeling: what software engineers do to understand a specific domain;
implicit models
System modeling: partitioning (look at small systems in pieces), abstraction (wh
at's common and specific to that system), projection (look at ways to solve each
of those pieces of problems)
Scenarios: descriptions of how a system is used in practices
Useful for adding detail to outline requirements description
Customer can tell you about different additions in scenario
Requirement Specificaiton: does not include the omodels built to help understand
the problem
Description of what the software must do
Document serves as reference throughout the remainder of the process
GOOD Specification:
1. Correct: ~59:40 AUDIO
2. Complete: system should describe all the customer wants in the softwa
re
3. Unambiguous: no room for confusion
4. Verifiable: how to check the requirement ahs been met
5. Consistent: can't conflict with each other
6. Ranked/Prioritized: things must have versus like to have
7. Modifiable: Easily modifable, where you may need to replace "10" to "
15" - config
8. Traceable: Mapping each design - corresponding testing, design, requi
rement

Specification Languages:
*Structured English*, Regular Expression, Decision Table, Finite state a
utomata
Common Pitfalls:
Describe what task the system does and implmentatino is how the system d
oes the task
Hidden requirement: "they're obvious!"
Different backgrounds - "what's so hard to understand here?"
Omitting stakeholder
IEEE Standard 830
1. Introduction
1.1 Purpose
1.2 Scope
1.3 Defintion, acroynms, and abbreviations
1.4 References - what documents are you using
1.5 Overview - what's in the rest of the document, where can i f
ind blah
2. General description
2.1 Product perspective
2.2 Product function
2.3 User characteristcs - who's using the system (peer group, an
d professor)
2.4 Constraints - has to be done in Java
2.5 Assumptions and dependencies
3. Specific requirements
3.1 External interface requirements
3.1.1 User interfaces
3.1.2 Hardware interfaces
3.1.3 Software interfaces
3.1.4 Comm. interfaces
3.2 Functional requirements
3.2.1 User class 1
3.2.1.1 Functional req 1.1
3.2.2 User class 2
3.3 Performance requirment
3.4 Design constraints
3.5 Software system attributes
3.6 --??-Requirements Validation
Demonstrating that requirements define the system that the customer real
ly wants
Requirements mangement
Identifcation numbering (verision ifnormation)
Requirements change mangemnt (CM)
Requirements traceability
Where is requirement implemented, do we need this, what ist he i
mpact, which requirement does this test case cover?
Summary:
Terminology (3 def)
Challenging for requirement engineering
Quality attributes
- Requirements
- Specification
Types of requimrents
Process of requimrents engineering

================================================================================
=============================
Management occurs in all phases
Project management occurs before requirement management
Software project mangement: on time, within budget, accordance with requ
irements
A process is not static
Process must be repeatable
Goal: Improve on the software management
Software management is uniquely flexible, complex, and dev. process is n
ot standardized
Many software projects are "one-off" projects (small variations)
Input: Software requirements
Output: Project Management Plan
3 main activities in this phase:
planning: developing master plan, where objectives are met (cost
estimation, schedule/milestone, staffing decision, develop more plans)
monitoring and control: money spent (in terms of effort), schedu
le tracking milestone, quality of artifacts generated, manage risks to success o
f the project
termination analysis: summarize info about project for process i
mprovement (gather proj. info, adjust process as necessary)
Effort vs Duration
Metrics, Measurements, Models
Objective and quantifiable - use numbers and actual measurement
~30-~35 the metrics
Measurements
Objective: clear measurement
Reliable: keep doing over and over again
Two Types of measurements
Direct:
Indirect:
Why do we need cost estimation?
One of the more important metrics, need to measure effort
Milestones shoud be T or F
QA Plan, deliverable product and intermediary steps are in check
Summary:
Role of project management and planning in the process
Metrics, measurements and models
Primary management activities
Components of project management (8 of them)
================================================================================
================================
COCOMO II
Cost estimation: prediction of person-effort + elapsed time

COCOMO: Scheduling and amount of effort

Can find out maintenance costs, reusability, tradeoff, project budgets,
and improvement decisions
Productivity: Personnel Capability - cost factor is huge versus document
ation
COCOMO has different models and tasks
Diseconomy of Scale Model Chart ~30 AUDIO
Page 15 - 30:00
Page 16 - 33:22
Life Cycle Obj. is piece of function you're trying to deliver
LC Architecture is characteristics of design and architecture to
cover risk sources
Page 20 - 36:05
Page 21 - 37:30
Page 22 - 37:40
Page 23 - 38:00
Page 24 - 39:55
Scale Drivers:

================================================================================
================================
** Did you build the right architecture?
Make sure requirements are met.
Can you see that everything can be satisfied in the requirement?