Embed Size (px)
Citation preview
Software Engineering
Lecture 1: Introduction
Why it is so hard to build a program?
A program is abstract
- Programmers and customers may not share the idea
- It is hard to estimate the work involved
A program is dynamic
- It is convertible : it is assumed that it is convertible
It’s hard to scale software engineering
- More programmers does not necessary make it faster
- The more programmer the more need for communication time
Building a software
Customer - Supplier
- What do we want ?
- How much does it cost ?
- When is it ready ?
Customer must be understood "widely"
- Internal
- Representative of the customer
For the customer, the project is usually a part of bigger picture (project)
Life cycle: requirements specification, design, implementation, verification, maintenance,
abandonment
Lecture 2: Software development process and life-cycle models
Agile Development
Process models: Same phases seen on every and each of the models.
Waterfall
SCRUM
Kanban
RUP
Requirement specification
Complete description of the behavior of a system to be developed and may include a set of use cases
that describe interactions the users will have with the software.
Before we can implement a system that resolves a problem, we have to know what the problem is!
There are 3 kinds of requirement:
Functional requirement : e.g. Software supports checking spelling
No-Functional requirement : e.g. The UI of the software follows the restriction of the style guide
Constraints and domain properties : e.g. The software has to be implemented in Windows
environment with C++
The hardest single part of building a software system is deciding what to build. No other part of the
conceptual work is as difficult in establishing the detailed technical requirements, including the
interfaces to people, to machines, and to other software systems. No other part of the work so
cripples the results if done wrong. No other part is more difficult to rectify later.
Two conclusions :
1. Use time to think through the requirements and writing them up before writing any lines of
code.
2. Requirements– or understanding about those – chance. So it is better to iterate one piece by
piece.
Architecture design
The technical features of the software :
Dividing the software in pieces: higher level structure of a software system.
Specifying the dependencies/relations
Specifying the interfaces
The software architecture of a system is the set of structures needed to reason about the system,
which comprise software elements, relations among them, and properties of both. The term also
refers to documentation of a system's "software architecture".
Documenting software architecture facilitates communication between stakeholders, documents
early decisions about high-level design, and allows reuse of design components and patterns
between projects.
Testing
Aims to finding bugs
Is also a an indicator for quality: How many percent of the test cases go through flawlessly
Consistent testing without a specification is impossible, because you cannot verificate the validity of
the result.
V-Model
Acceptance Test
Did we get what we wanted ?
What does the customer thinks ?
Waterfall process model
Spiral process model
Agile methods process model
Iterative and incremental
Minimal design, small tasks
”Being open to changes”
Deliver early and often
Develop iteratively, possibilities for changes
User stories
Develop ”good enough”
Problem description
Communication, feedback, transparency, visibility
Trust
Self-organization
Lecture 3: SCRUM
Actually, 35% of organizations uses agile methods (11% uses SCRUM), 21% uses iterative methods, 13%
uses waterfall methods and 31% doesn't use any formal process methodology.
Why agile ?
Continuous visibility (does not fix problems, but makes them visible)
Possibilities for changes
Earlier business value
Lower risks
Agile manifesto
We are uncovering better ways of developing software by doing it and helping others do it. Through
this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
SCRUM is a Framework for agile and iterative development.
Scrum can be summarized as :
3 roles
4 ceremonies
3 artifacts
Most properties of Scrum relate either of these concepts of estimation and time boxing.
3 ROLES
3 Pigs :
Product owner (PO) : Owns the product,
represents the stakeholders and is the voice of
customer.
Scrum master (ScM) : Owns the process, ensure
that the SCRUM process is used as indented.
Development team : Responsible for delivering
potentially shippable product increments at the
end of each sprint.
Everyone else is chicken (manager, interest groups :
customer, vendor...).
4 CEREMONIES
A sprint is a period of max 1 month, preceded by a planning meeting, where the tasks for the sprint
are identified and estimated.
Sprint planning meeting
Daily Scrum : each day during the sprint, answer to 3 questions with specific guidelines.
Sprint Review
Retrospective (Backlog grooming, Abnormal sprint termination)
3 ARTIFACTS
Product backlog : a prioritized list of high-level requirements. It contains all product backlog items
(user stories) and it's owned by PO.
Sprint backlog : a prioritized list of tasks to be completed during the sprint. It contains selective
backlog items and it's owned by development team.
Impediment list : the sum of all the product backlog items completed during a sprint and all previous
sprints, owned by the ScM.
Estimating work
As small tasks as possible
Some known estimation point: gummy bears
Estimates do not have to be ”right” but they have to consistent
Time boxing
The sprint is the main unit of time boxing
A sprint represents a development team forecast
During a Sprint: priorities cannot change, there may be no new external requirements
Responsibilities
Single wringable neck
Everyone has their own responsibilities
Achieving an accountable task should be demonstrable
Everything is based on trust, each and everyone makes the best they can.
Burndown chart
It allows to visualize graphically remaining work in the sprint backlog (updated every day).
Done means: 100% done!
Velocity -> how many tasks can be done in one sprint
Hours are reduced from the chart, if the task is 100% ready
If the task increases, hours are added on the chart.
Applying Scrum : we should not forget that Scrum is just a framework, but Iterativity ?
Iterations less than four weeks
Features are tested and working before the end of iteration
Iteration has to start before the specks is ready
Other characteristics about applying Scrum :
Who is the product owner?
Backlog is ordered by business value
Estimates are made by the team
Burndown charts are done and velocity of the team is known
No project managers
Lecture 4: Project planning and management - PART 1
Software project management concerned with activities to ensure that :
Software is delivered on time.
In accordance with the requirements of the client.
To monitor the project is within the budget and schedule constraints.
Estimating workload
The corner stone of scheduling
Estimation: defining task size, cost, resources and duration.
Estimates will be defined more during the project.
In the beginning estimates are made as well as possible. Estimates will become more
accurate in time.
Work breakdown structure : by structure, work type, phase, systems.
Estimating is difficult because :
Requirements changes
Project goal and content is poorly defined
Project organization, regulations... changes
Estimators are inexperienced
Estimates are too wide scale
No data from the history accessible
Personnel changes
Management makes the estimates
Poor management
Different models for estimating workload :
"Education quesses" : based on experience
COCOMO (Constructive Cost Model) : based on lines of code, cost drivers. Result : ideal
calendar time.
FPA (Function Point Analysis)
Three estimate model : Pessimistic, probable and optimistic estimate
Planning poker
Estimation work contribution
1 person in one project ->5 days of work but
holidays, education, work for other projects
time spent in emergent requirements
Not-productive work (meetings, inspections, travelling)
Estimated work contribution for one software developer: 60-70% of the whole working time.
Tracking the project : DIVIDE AND CONQUER
Project Schedule : Is a time line that shows when activities will begin and end, and when the related
development products will be ready.
Phase : Subdivision of a project according to logical grouping of work. Phases might be carried out in
sequence.
Step : Subdivision of a phase. A step can might consists of number of activities.
Activity : A single task within a step that take place over a period of time.
Milestone : Is the completion of an activity - a particular point of time.
Project progress :
Activity graph of project progress :
Activity graph depicts dependencies among activities.
Customer can follow the progress.
Developers can point out current and future activities.
Following milestones
Completed work
Describing an activity
Precursor: (set of) Events that must occur before the activity can begin.
Duration: Length of the time needed to complete the activity.
Due date: Deadline. Date by which the activity must be completed.
End point: Milestone or deliverable.
Nodes : Describes the project milestones.
Edges : Represents the activities involved between milestones.
Characteristics :
+ Suitable for projects in which activities can be done in parallel.
+ Precursors to start certain activities.
+ Which activities can be carried out in parallel / simultaneously.
- If there is less parallelism in tasks then activity graph will not be useful.
CPM (Critical Path Method)
Algorithm for scheduling a set of project activities.
Activities listed, tracking the dependencies of the activities, duration of the activities, duration of the
paths -> The longest path is CPM.
It shows the most critical activities of the project that must be completed in time to keep the project
in schedule.
Slack time = Available time - Real time = latest start time - earliest start time
Real time = estimated amount of time required for the activity to be completed.
Available time = amount of time available in the schedule for the activity’s completion.
If an activity on the critical path delays, then all the subsequent activities delays -> Eventually the
project delays.
If there are loops in the path then it would be even harder to determine the critical paths.
Risk management
The project risks can be divided into the following types:
Technical risks
Schedule Risks
Cost Risks
The organization, personnel, information flow
External procurement, suppliers
Customer-related risks
Environmental Factors
Risks relating to the contract
Export projects to the country risks
Organizational Structure and People
For determining project schedule and to estimate associated effort and cost, we should know :
How many people will work.
What would be their responsibilities.
Expertise area and experience.
Things to consider when selecting staff and their role :
Novelty of the work - some feel good to do new things..
Security - some love to do in what they are good at.
Experience, training and expertise on similar tools, techniques and applications - given equal
ability and interest two people must differ in their productivity if one of them has prior
experience on similar projects.
Communication : Project's progress is affected not only by the degree of communication, but also by
the ability of individuals to communicate their ideas.
For n workers : n(n-1)/2 pair of communication path and 2n - 1 possible team.
Project organization :
Hierarchical approach :
Egoless approach :
Everyone equally responsible.
Criticism is made of the product or the result, not the people involved.
Democratic process and all the team members vote for a decision.
Project which is relatively large with high degree of certainty, stability, uniformity and repetition can
follow hierarchical organization.
Project which is relatively small with high degree of uncertainty such as requirements not clear or
might change at any time, small project can follow egoless approach.
Projects may combine these approaches whenever needed.
Project Plan Document
Lecture 5: System modeling and software engineering models
Modeling the system
Models aim for efficient and precise communication and documentation.
Abstractions (simplifications) of reality.
Different levels of abstraction.
Communication between domains ( problem -> design -> implementation)
To represent models, the organization needs to adopt standards and guidelines to be practiced.
First step: Settle on a common notation. UML defines the notation and semantics for common
object-oriented models.
Second step: Set modeling style guidelines for creating consistent and clean looking diagrams.
Third step: Enact modeling standards and guidelines through training and mentoring the staffs.
Use case diagrams
A graph that displays actors, use cases, and their relationships, very simple notation.
A UML use-case diagram shows the relationships among actors and use cases within a system.
Use-case models should be developed from the point of view of project stakeholders and not from
the (often technical) point of view of developers.
Use-Case guidelines
Begin Use-Case Names with a Strong Verb as Withdraw Funds, Register Student in Seminar, and
Deliver shipment.
Name Use Cases Using Domain Terminology.
Imply logical timing Considerations by stacking Use Cases.
Actor guidelines
An actor is a person, organization, local process (e.g., system clock), or external system that plays a
role in one or more interactions with the system.
We should draw Actors on the Outside Edges of a Use-Case Diagram. We should not allow Actors to
Interact with One Another.
Actors with singular and domain-relevant nouns: That accurately reflects its role. Associate Each
Actor with One or More Use Cases.
<<system>> is to Indicate System
Actors: The <<system>> stereotype is
applicable to system/concrete
diagrams that reflect architectural
decisions made for the system.
Introduce an Actor Called “Time” to
Initiate scheduled events.
Relationship guidelines
an association between an actor and a use case,
an association between two use cases,
a generalization between two actors,
a generalization, includes and extends among use cases.
Associations are represented as:
Lines connecting two modeling elements.
An optional open-headed arrowhead on one end of the line, indicating the direction of the
initial invocation of the relationship.
Generalizations are depicted as closed-headed arrows pointing toward the more general
modeling elements.
Apply <<include>> When You Know
Exactly When to Invoke the Use Case:
association is as the invocation of
one use case by another one, just
like calling a function or invoking an
operation within source code.
Apply <<extend>>: A generalization
relationship where the extending
use case continues the behavior of
the base use case by conceptually
inserting additional action sequences into the base use case.
Generalize Use Cases When a Single Condition Results in Significantly New Business Logic.
System Boundary Box Guidelines
The rectangle around the use cases is called the system boundary box. It indicates the scope of the
system.
Indicate Release Scope with a System Boundary Box.
Avoid Meaningless System Boundary Boxes.
The contents of a use case can for example be described as follows:
Name of the use case: A Descriptive Name
Actors: list of participating actors
Preconditions: Which conditions apply in the beginning of the use case
Description: Informal description (text, pictures, state diagrams, activity
diagrams, interaction diagrams)
Exceptions: exception conditions (included in the description in brackets [ ])
Post-conditions: Conditions that apply at the end of the use case
Other conditions: Non-functional requirements.
Example : Class-roam reservation system
A university class-room reservation system can be accessed by the lecturer, course assistant and the
maintenance officer. Both lecturer and the assistant can reserve a room, with the lecturer and the
maintenance officer has the privilege to cancel a prior reservation. Reservation can be made to a
auditorium and conventional class rooms. To perform any of the above mentioned actions, user must
provide and authenticate their identity first.
Why use cases ?
Connecting customer requirements to the system’s functions
Enables a common understanding of the system under development
Defines the boundary of the system
Helps to recognize who or what is using the system
Specifies the higher level functionality of the system
Specifies the basic terms of the system
Helps identifying objects/subsystems
Helps in assigning responsibilities/functionality to different parts of the system
Can be used for organizing software development (planning iterations)
Can be used in design of test cases
Can be used in writing user manuals
Class diagrams
Displays classes of a system and their interrelationships and their attributes and operations.
By far the most important diagram type in all OO methods.
Used from domain analysis to implementation.
A rich notation.
They are used to analyze requirements in the form of a conceptual/analysis model and represent the
detailed design of object-oriented or object-based
software.
Class
Indicate language-dependent visibility with property
strings.
Indicate Visibility: The visibility of an operation or
attribute defines the level of access that objects have
to it.
Guidelines :
Be Consistent with Attribute Names and Types
Use Common Terminology for Class Names
Prefer Complete Singular Nouns for Class Names
Name Operations with Strong Verbs: Operations implement the functionality of an object
Name Attributes with Domain-Based Nouns
Do Not Model Scaffolding Code
Do Not Model Keys: Keys are a data concept, not an object-oriented concept
Include an Ellipsis ( . . . ) at the End of an Incomplete List
Label Uncommon Class Compartments (constraints...)
List Static Operations/Attributes Before Instance Operations/Attributes.
List Operations/Attributes in Order of Decreasing Visibility.
For Parameters That Are Objects, List Only Their Types.
Avoid Stereotypes Implied by Language Naming Conventions: <<constructor>>, <<getter>>...
Indicate Exceptions in an Operation’s Property String
Relationship
Relationships will include all UML
concepts such as associations,
aggregation, composition,
dependencies, inheritance, and
realizations.
Guidelines :
Model Relationships Horizontally.
Model Collaboration Between Two Elements Only When They Have a Relationship.
Model a Dependency When the Relationship Is Transitory (short-lived or temporary):
Transitory relationships—relationships that are not persistent—occur when one or more of
the items involved in a relationship is either itself transitory or a class.
Always indicates the multiplicity (try to avoid 0..* or 1..* -> not accurate)
Do Not Model Implied Relationships.
Write Concise Association Names in Active Voice: For example, “places” instead of “is placed
by”
Indicate Directionality to Clarify an Association Name. Indicate the directionality on recursive
associations, where the association starts and ends on the same class.
Indicate Role Names When Multiple Associations Between Two Classes Exist.
Inheritance
Inheritance, also called generalization, models “is a” and “is like” relationships.
Guidelines :
Place Subclasses Below
Super-classes.
A Subclass Should Inherit
Everything.
Indicate Power Types on
Shared Generalization: Power
types, a meta modeling
concept, can be indicated
using a role name associated. with a generalization relationship.
Aggregation and composition
Represents “is part of” relationships.
Be Interested in Both the Whole and the Part. Place the Whole to the Left of the Part.
Apply Composition to Aggregates of Physical Items.
Apply Composition When the Parts Share Their Persistence Life Cycle with the Whole.
Interaction diagrams
Sequence and collaboration diagrams: describes a scenario of object interactions and has a simple
notation.
Statechart diagrams
Describes the functionality of an object (or any system)
A rich notation, systems can be modeled to almost any level of detail (enables code
generation)
Activity diagrams
UML standard : An activity diagram is a special case of a state diagram in which all (or at least most)
of the states are action or subactivity states.
Lecture 6: System modeling
UML sequence diagrams
A sequence diagram shows, an interaction arranged in time sequence. In particular, it shows :
The instances participating in the interaction by their “lifelines”
The stimuli they exchange arranged in time sequence.
It does not show the associations among the objects.
Frame: The frame element is used as a basis for many other diagram elements in UML 2. In sequence
diagram it shows the graphical boundary. It’s optional in UML.
Lifeline: Time interval between creation and destruction of an instance of a class.
Message: First message starts at the top-left side of the diagram.
When sending a message to another object :
Synchronous call operation: draw a line to the receiving object with a solid arrowhead.
Asynchronous call: draw a stick arrowhead.
The message/method name is placed above the arrowed line. The method is implemented in the
receiving object's class.
Return messages are optional.
An object can send a message to itself.
Guards / Operators
When modeling object interactions, there will be times when a condition must be met for a message
to be sent to the object. Guards are used throughout UML diagrams to control flow.
Operands are separated by a dashed line.
Each operand is given a guard to test against.
Guard is placed towards the top left section of the operand on top of a lifeline.
If an operand's guard equates to "true," then that operand is the operand to follow.
The parallel combination fragment is drawn using a frame. The frame's content is then sectioned into
horizontal operands separated by a dashed line. Each operand in the frame represents a thread of
execution done in parallel.
Gate is an alternate way to referencing another sequence diagram: A gate is merely a message that is
illustrated with one end connected to the sequence diagram's frame's edge and the other end
connected to a lifeline.
UML package diagrams
UML package diagram represents two or more packages and the dependencies between them.
Helps to organize model elements, such as use cases or classes, into groups.
Packages are represented as file folders and can be applied on any UML diagram.
Package diagram are used to
Depict a high-level overview of requirements.
Depict a high-level overview of design.
Logically modularize a complex diagram.
Organize source code.
Guidelines :
Create Class Package Diagrams to Logically Organize the Design.
Heuristics to organize classes into packages
Classes of a framework belong in the same package.
Classes in the same inheritance hierarchy typically belong in the same package.
Classes related to one another via aggregation or composition often belong in the same
package.
Classes that collaborate with each other a lot often belong in the same package.
Place Inheriting Packages below Base Packages.
Vertically Layer Class Package Diagrams.
For larger projects, UML package diagrams are often created to organize usage requirements.
Create Use-Case Package Diagrams to Organize Requirements : Keep associated use cases
together: included, extending and inheriting use cases belong in the same package. Group
use cases on the basis of the needs of the main actors.
Arrange Use-Case Package Diagrams Horizontally.
Give Packages Simple, Descriptive Names as customer, enrollment, shipping.
Make Packages Cohesive: Whether a package can be given a short, descriptive name.
Avoid Cyclic Dependencies Between Packages as A->B->C->A. It's harder to test, maintain,
and enhance over time.
UML State Machine Diagrams
State Machine diagrams represent the behavior of entities capable of dynamic behavior by
specifying its response to the receipt of event instances.
Typically, it is used for describing the behavior of classes. It may also describe the behavior of other
model entities such as use-cases, actors, subsystems, operations, or methods.
States : A state is denoted by a round-cornered rectangle with the name of the state written inside it.
The initial state is denoted by a filled black circle.
The final state is denoted by a circle with a dot inside.
Both may be labeled with a name.
Transitions from one state to the next are denoted by lines with arrowheads.
Trigger is the cause of the transition, which could be a signal, an event, a change in some condition,
or the passage of time.
Guard is a condition which must be true in order for the trigger to cause the transition.
Effect is an action which will be invoked directly on the object that owns the state machine as a
result of the transition.
State actions
If the target state had many transitions arriving at it,
and each transition had the same effect associated
with it, it would be better to associate the effect with
the target state rather than the transitions.
Entry action for the state, when a transition
enters an state.
Exit action for the state: when a state is
leaved.
Self-Transitions : A state can have a transition that returns to itself, as in the following diagram. This
is most useful when an effect is associated with the transition.
Compound States : A state machine diagram may include sub-machine diagrams.
Entry point : There may be multiple entry point in a sub-machine.
Exit point : There might be alternative exit points.
Choice Pseudo-State : A choice pseudo-state is shown as a diamond with one transition arriving and
two or more transitions leaving.
Junction Pseudo-State : Junction pseudo-states are used to chain together multiple transitions. A
single junction can have one or more incoming, and one or more outgoing, transitions; a guard can
be applied to each transition.
Terminate Pseudo-State : Entering a terminate pseudo-state indicates that the lifeline of the state
machine has ended.
History States : To remember the previous state of a state machine when it was interrupted.
Concurrent Regions : A state containing sub-states that exist and execute concurrently.
Fork and join pseudo-states : These symbols are used to synchronize the concurrent threads.
Example
Lecture 7: Estimating work effort
Why ? -> Keystone of scheduling
What ? -> Counting, defining and estimating task sizes, costs, resources and durations, Estimates are
defined all along the project
How ? -> Different methods (chosen by project type), Small tasks (reference point), Estimates do not
have to ”be right” but they have to be made with same principles
Basic rule
If you under estimate one task, over estimate next one
Include some leeway (extra time) in your estimates
Use history data
Duration = work load / resources
Estimation of workload
Estimating program size K with some measure : lines of code, amount of classes or screens...
KLOC : Kilo (Thousand) lines of code
LOC/MM (man month)
FP (function points)/MM
Estimating productivity b (lines in one day).
Work effort estimation types
Effort estimation can be broadly categorized into
1. Process based estimation : Expert judgment (based on manager experience with similar
projects), Analogy (if system A is similar to system B then cost of producing system A would
be very similar to producing system B)
2. Problem based estimation : COCOMO, FP analysis
Tools for estimating work load
Planning poker
Model of three estimates
Analogy (educated quess)
Cocomo (constructive cost model)
FPA (function point analysis)
Putnam, Myers
Sad paradox: Wrong estimators are the best dealers
Planning poker
It's a method which is widely used in agile world. Participants get a deck of cards with different
numbers ( 0, 1, 2, 3, 5, 8, 13, ..., infinity), then Issue that has to be estimated is presented.
Everybody choose a card that describes their opinion about the work load. Cards will be shown at the
same time, estimators that show the most divergent views, each will defend their views.
Process will be repeated until consensus is reached, the result is more accurate and less optimistic
than mechanically counted estimate.
Model of 3 estimates
Three estimates : PESSIMISTIC (a), PROBABLE (b), OPTIMISTIC (c)
(a+ 4b + c)/6
Example : a = 20 weeks, b = 12 weeks and c = 10 weeks -> estimate = 13 weeks
Educated quess
“When you take into account all of the facts that you are aware of and draw your best
conclusion about the answer”
”Hypothesis”
Maybe the most used estimation method
COCOMO
Basic COCOMO computes software development effort (and cost as a function of program size).
Coefficients of the model are internationally collected statistical data.
Classifies software as:
1. Organic software
2. Embedded software
3. Semi detached software
Three empirical models/levels:
1. basic model: man months are estimated (LOC)
2. intermediate model: man months (LOC) and cost drivers
3. advanced model: man months with intermediate model and cost drivers in every phase of
development cycle
Inputs (depending on the model):
Size of the product (SLOC, source lines of code)
Scaling factors
Every part of the project: cost drivers (Product attributes, Hardware attributes, Personnel
attributes, Project attributes)
Outputs
Effort applied
Development time
Work load PM = Personal Month : nominal schedule
In the end, we get PM by multiplying it with PMNS which is a coefficient that describes the tightness
of the project schedule (SCED).
Calendar time / development time :
Scaling coefficient SFi : Each and every factor is estimated by 6 step scale (very low, low, nominal,
high, very high, extra high)
Cost coefficient EMi :
Example :
COCOMO - ADVANTAGES :
Can be used in many ways, very profound, information easy available
good to use as a part of retrospective
“reason its good and bad characters”
use on negotiations with different sides
can give reasons for technology choices, process improvements,...
COCOMO - CRITICS :
Basic COCOMO gives very crude estimates and intermediate model does not provide any
substantial improvement
”Heart” of COCOMO is based on waterfall
Does not work well for small project
Too many parameters needed for intermediate COCOMO
Function point analysis
Can be used to estimate the size and technical complexity of the software.
Inputs :
function points
complexity of a system
a factor depending on a programming language
Results :
fixed (corrected) function point amount
amount of code lines
Counting the function points :
User inputs: for example dialog could be one and its complexity tells, should we add one into
the simple, moderate or hard box.
User outputs: for example a report or some view and their complexity estimation.
User queries: for example word counts, query results or status questions about the software.
Number of files: external files or internal files (or file structures, databases, large data
structures) that the system creates dynamically.
Number of external interfaces: for example data communications, databases,
communication with a device etc, that is, parts that are external to the system.
Counting the function points - complexity factors :
1. Data communication requirements.
2. Distributed functions.
3. Efficiency criticality.
4. Are the target system devices on heavy use?
5. Number of transactions (frequency).
6. Inputs of on-line data (do we have views and many functions).
7. Efficiency of end use.
8. On-line updates.
9. Complex processing.
10. Reusability of code.
11. Installation easiness.
12. General easy to use (e.g., startup time, backup copies).
13. Can be installed in many different environments?
14. Observing changes (can the user configurate the software flexibly).
Each item is estimated with grades:
0 — no impact (is not considered)
1 — should be somehow considered / implemented
2 — should be moderately considered / implemented
3 — considered as usual
4 — important
5 — required
Each estimate is marked with F i, and in the end we’ll get: the number of function points is “totaling
corner” × (0.65 + 0.01 ×P 14 i = 1 F i ).
CONCLUSION
Use mixed methods
Use history data
Use your guts
Do not under estimate
Software costs
Labour costs (salaries etc ) 50-70% of all costs
Overhead costs (rents, office costs, phone, post..)
Subcontracting
Equipment costs
Education
Bonus system
Travelling costs
Literature, data acquisition
Capital outlay
Marginal profit
Etc..
Personnel costs
Salary (salary/month, overworking, bonus)
Social security costs (holiday remuneration, social security, retirement costs, insurances,
sickness, benefits, midweek holidays, takes 50-60% of the salary)
Voluntary personnel costs (food, car, health care, recreation )
Education
Recruiting (can really be a significant cost, 6-10 months' salary?)
Rough price estimate
Average salary should be charged by multiplying 2,5-4 x
Basic hour cost: Costs factors / counted invoiced hours
Invoiced hours: All scheduled time (225days/person/year = 1700h)
Projects price:
Time estimate * basic hour price
Equipments, software, hardware
Other costs..
Example
Lecture 8: Quality assurance, Inspections and Testing
How to confirmed that quality is good ?
Measuring quality
Testing
Inspections
Quality - Definition :
The ability of a product to meet the needs and expectations of a customer
Correct product, correct process, in correct time
Objective quality: produced as specificated
Subjective quality: meets the expectations of the user (customer). Different users have
different expectations
Quality system defines the methods used in company.
Quality components in ISO 9126 :
Audit / Review
Auditing: Quality system evaluation, made by person that is not related to the audited target (audit,
assessment, review).
Quality audits are performed to verify conformance to standards through review of objective
evidence.
Audit can be internal or external :
Internal: company performs audit itself
External: someone out of company performs the audit
Formal ceremony, during which the quality of the product or operation is audited (reviewed) by
comparing it to documentation or standard.
Testing
Software testing is a process, or a series of processes, designed to make sure computer code does
what it was designed to do and that it does not do anything unintended.
Specifying,
Bug searching
Measuring quality
Test case: describes inputs, with which the program is tried to get in failure
Testing procedure: describes the testing steps.
Testing environment: hardware and development environment with which the target of test is take
up with
Testware: all the documents and products that are created for testing: testcases, plans etc
Validating: ensures that product is what it should be
Verifying: ensures that product is done how it's should be done
White-box testing: test cases are created based on code
Black-box testing: Equivalence partitioning and Boundary-value analysis
When the size of tested unit gets bigger: white-box testing-> black-box testing
Continuous testing
Future
Testing and requirements set for testing are increasing and becoming more complex. Testing is
becoming closer to programming => ”testware engineering”.
Consequences :
Testware engineering is more essential part of product development and it is integrated even
more clearly in every phases of software production all along the life cycle.
Testing cannot be anymore ”a secondary job”. There is an increased need for experts. Part of
the testing personnel are also good programmers.
For the development and maintaining of testing material and environments there has to be
developed disciplined and well defined processes and tools, as there are in the field of
software production.
Increased need for regression testing increases also automated testing and testing tools
Testing is even more related to specifications, and may also sort of compensate that
(documented test cases can be seen as specification)
Testing the tests should catch more attention
Factors that increase the amount of testing and the complexity of that :
There should be more code, faster, more effectively, with better quality..
Change of production process (Iterativity, Results of testing are used as process measures,
release management, Testing of non functional features...)
Characteristics of testing :
Testing is systematic search for bugs. Not a random run of program
Testing is suppose to point out, that there are bugs in the program
The more bugs, the more successful test
A bug is a conflict between specification and implementation
Tracing the bugs, debugging, is not testing
Tasks :
Writing test plan : The first version already when doing the specification, goals of testing in
each test, planning test cases in each test
Creating testing environment
Performing testing
Inspecting results
Bug searching method
The size of input space and possible outcomes is so huge, that even a tiny program cannot be
tested inclusively.
In real time systems it is even more problematic.
So, by testing, you can prove that there are bugs in the program, not that the program is
error free.
Error : man made. For example a bug or a mistake in document
When incorrect code is performed (or code is missing) it may cause a fault. System is then in a state
that is not specificated.
Fault may lead to the system deviating from its desired behavior - a failure
Problems :
Attitude: Testing is used to prove that the program is working, not that it is not.
Underestimating: ”those who cannot do anything else, are testing”
When can testing be finished? When there is no money or time left?
Is everything really tested?
To where do corrections really effect?
Repeating tests after corrections (amount of regression test)
Repeatability of a test (timing and other unmanagable phenomena)
Other problems for testing :
Putting up a testing environment
Effect of testing tools on system behavior
System is geographically wide (decentralized)
Detecting deviations is difficult
Correct outcome is not necessary known
Situations that cannot be organized in testing (software usually have these parts)
Verifying results, when the functioning of a system cannot be follow outside
V-Model
Planning test cases early is useful but there is also a problem included: wasted effort.
Unit testing ensures that each module works as specificated, generally 100-1000 lines.
The functionality is compared to specification
Programmers usually test unit tests themselves
Sections of unit testing: Data structures, interfaces, loops, error procedures, boundary values
TDD (Test-Driven Development): unit testing iteratively
Integration testing : test combined software modules.
Testing progresses simultaneously with module testing.
Incremental : Bottom up (lower level module first) / Top down (higher first)
Big bang: First unit tests, then integrating all
System testing : supposed to ensure that system works as specificated.
Testing can/should be performed by an outside group
Fixing bugs is expensive
Reliability-, recovery-, safety- and stress tests (response times, volumes)
Compatibility with other systems
Other forms of testing :
Field testing
Acceptance testing
Alpha testing
Beta testing
Regression testing
Release testing
Usability testing
Performance test
...
Conclusion
Meaning (and amount) of testing has increased => meaning of test automation is emphasized =>
more testing experts needed.
Is it possible to get professionals get interested in testing?
”Well achieved tests cannot save a bad program”
Best way to keep the amount of testing reasonable is to produce less bugs
If/when bugs are produced, they should be get off from the product as early as possible
Testing is not just running test cases, it is also acquiring knowledge about quality
There are no best practices
Inspections and auditions
Review (Technical)
The purpose is to find that one phase/stage is ended. Making proceeding visible/noticeable
In the most important milestones, for example in the end of specification or design phase.
Covers entire delivery
Many participants. Also outsiders
Inspection
Purpose is to find fails/failures. Flexible schedule, many in one phase
A few participants (3-6), internal
Walkthrough
Informal form of inspection. For code usually
Coder explains what she thinks the program is doing
Audit, assessment: auditing quality system and operation of an organization.
Management review = state of the project is reviewed (or the state of whole quality system, ISO
9001)
Verifying: product meets its specification
Validating: product is suitable for the purpose of use
Virtual reviews: review can be carried out on web without a meeting. Used in OSS-projects.
Pair programming: used in agile method, where when coding, there are two person in front of one
screen: real time review.
Architecture review: many review methods have been developed (ATAM, SAAM).
Cost of failure :
The longer the bug exists on the system, the expensive it becomes
It has been verified many times, that over half (60%) of the bugs found from the product is
from the phases preceding coding (specification, design)
Testing and eliminating the bugs takes 50-80% of the time of the project
Maintenance includes over half of the life cycle costs
Conclusion: Do invest in preventing and recognizing the bugs early on.
Inspection
Max. 2 hours, synergy: new faults/failures found
No explaining and defending, No point collecting, No blaming
Session cannot change to creation meeting
Searching bugs and errors – no fixing
Result and follow up arranged
Document is a record of participants, Time consumed / participant, approved / failed,
Schedule for fixings, error summary, Follow up procedure
Roles :
2-6 persons
Creator/coder
Presenter: presents the material (can be the creator)
Secretary: writes down the failures
Inspector: all are inspectors
Other roles: experts, users..
Instructions : be prepared, be kind, do not offend the creator, stay in technical stuff, evaluate the
product not the creator, give also positive comments, focus on problems.
What is inspected ? : List below is in priority order
Offer, contract (ISO 9001).
Specification documents (functional specification).
Project plan
Design documents (technical specification
Testing plans
Code
Documentation for the customer
Education material, education plan
Implementation plan
Effects of inspections
Many errors cannot be found by testing
The purpose is to find errors => challenging proses for human beings
80% errors can be found in inspections (= more than by testing).
Inspections take approx. 5-15% of the work load of the project
Advantages : Deputy, Learning, Familiarizing with others work, Commitment on the results
Worst problems
Attitudes and organizing the inspection session
Participants are not prepared
Amount of work when familiarizing with the subject
Motivating, attitudes
Sprawling
Soft preside
Ideas fixing
Amount of work is not included and taken into account in scheduling. Especially inspections
of other projects
Too much material
Observations
First there were 40-50 bugs / 1000 lines of code, 80% of those is possible to find in inspections,
among them some bugs that cannot be found in tests :
Unnecessary code
Code that does not follow standard
Failures in comments
Testing is more expensive than inspections.
Problems of inspection :
No proves that inspections are effective
Inspections take a lot of time (errors even more)
Misunderstandings about inspection technique: any kind of commenting can be seen as
inspection..
"Low tech" imago, people think that testing and tracing is faster
Lecture 9: Software licenses, IPR, OSS
IPR
IPR : Intellectual Property Rights
Is defined in law
Different countries have different laws
License contracts : between 2
Price
Delivered and used software
Terms and restrictions of use
Responsibilities of both
Different types of IPR :
Patent : Software inventions can be patented
Copyright : Can protect the source code, UI, Application programming interface (API)
Trade secret
When making a contract :
Do you buy just the binaries or source code
Documentation?
Who has right to redevelop
The components in the product, dependencies?
Organization renovations, trade sales
For a private person :
Buys a product from the store
Bins license conditions
installs the software
enters the activating code
Downloads software from internet
Pays to get the code
lies that has read the conditions
installs and activates the software
License audits : Instead of strict and heavy technical sanctions: audits -> is the use in agreement with
the terms of license.
Audits are on the rise
Payments, contractual penalties.. And a lot of lawyer costs
OSS
Basic ideas of Open-Source Software:
When programmers can read, redistribute, and modify the source code for a piece of
software, the software evolves.
People improve it, people adapt it, people fix bugs.
And this can happen at a speed that, if one is used to the slow pace of conventional software
development, seems astonishing.
Open source does not just mean access to the source code. The distribution terms of open-source
software must comply with the following criteria :
Free Redistribution
Source Code
Integrity of The Author's Source Code
No Discrimination Against Persons, Groups, or Fields of Endeavor
Distribution of License
License Must Not Be Specific to a Product
License Must Not Restrict Other Software
License Must Be Technology-Neutral
Free software is
A philosophy
A social movement
FSF, free software foundation
Stallmanism
Open source is
A business model
A development methodology
OSI, open source initiative
Raymondism
Elements of OSS
Open development methodology
Constant and thorough peer reviews
Transparency of development process
Global distribution
Open Source Software license
Set of well-defined licenses whose terms define what and what not can be done with the
software.
Lot of incompatibilities; do not always mix with proprietary code
Community
Individuals, companies, and organizations are free to participate
(Somewhat) shared mission often needed for driving the community towards a common goal
OSS - The Method
The promise of open source is better quality, higher reliability, more flexibility, lower cost, and an
end to predatory vendor lock-in.
Ideally, participation in the community need not be restricted in any ways. Practice can however
make the difference! In addition, adequate tools are needed!
Technical infrastructure
Managing Brooks' law
Adding more programmers to a late project makes it later
Web site (GitHub, SourceForge)
Mailing lists / discussion forums
Version control
Bug tracking
Real-time chat
OSS - The License
Who writes the code owns the copyright, and can decide the license.
A way to publish software with the right...
to make copies and distribute software
to have access to the software's source code
to improve software
License :
With Copyleft (GPL, LGPL, Mozilla (weak copyleft) etc.)
Without Copyleft (BSD, Apache)
Viral effect – open and proprietary can touch only if allowed
Patent & IPR – you can choose NOT to use open source
Dual License – if you own the copyright, then you decide which license
GNU GPL : Free distribution; if you get the binary, you should be able to get the code
Derivatives also GPL, must be distributed on equal terms
Viral for code -> Safe for community, often considered dangerous for companies
LGPL :
Lesser GPL, less ”sticky” when used in connection with other software components
No viral effect
BSD, MIT, Apache : Liberal; commonly used in universities
MPL, Eclipse : Sticky, used for ex per Nokia, Sun, IBM...
Definitions made by lawyers rather than by developers, in general more precisely defined
than their counterparts in GPL
A lot of incompatibilities exist for OSS licenses : for example GPL2 and GPL3 are not compatible.
Consequence : Technically sound systems may violate licenses.
Problems with OSS
For end user : No guarantees, at one’s own risk
As a part of own product :
No guarantees,
Using OSS may require publishing your own code
IPR - risk
