eCommerce Technologies and Infrastructures
Diomidis Spinellis
Department of Management Science and Technology
Athens University of Economics and Business
Athens, Greece
dds@aueb.gr
Application architectures
Architectural Dimensions
- Design properties
- System structure
- Control model
- Element packaging
- Architectural reuse
Basic Design Principles
When designing a system's architecture we try to follow the
principles outlined below.
Abstraction
Abstraction is achieved in the following areas:
- procedural abstraction
- data abstraction
- control abstraction
Refinement
Stepwise refinement is a way to tame the details and
complexity of the final design.
Modularity
A modular design minimises the system's complexity and thereby
the development cost and the number of possible errors.
A good design method should provide:
- modular decomposability
- modular composability
- individual modular understandability
- modular continuity
(in changes: minimize the modules affected by any change)
- modular protection:
a problem in one part should not create problems in others
Cohesion
A design should bring closely together parts that exhibit a
high measure of cohesion.
We can distinguish the following ordered types of cohesion:
- coincidental cohesion
- logical cohesion
- temporal cohesion
- procedural cohesion
- communicational cohesion
- sequential cohesion
- functional cohesion
Coupling
On the other hand, a design should avoid coupling between
parts.
We can distinguish the following ordered types of coupling:
- data coupling
- stamp coupling (copy of a part)
- control coupling
- common coupling
- external coupling
- content coupling
A: System Structures
Important and noteworthy system structuring
models include the following:
- Centralized repository
- Data-flow
- Object-oriented
- Layered
- Hierarchical
Centralized Repository
- Central process acts as control hub
- Central data repository acts as information hub
- Termed client-server when based on standalone processes
- Integrability allows different clients and servers to interoperate
- Depending on persistency requirements:
- A blackboard can store temporary data acting as a communications hub
- A relational database can provide a persistent data store
- In a two-tier architecture the client accesses the database
- In a three-tier architecture a separate server offers task-oriented services
- A transaction monitor can be used to offer
- Resiliency
- Redundancy
- Load distribution
- Message sequencing
- Middleware allows different parts to communicate with each other
- CORBA (OMG)
- .NET (Microsoft)
- RMI (Java/Sun)
Examples
- Window manager
- File server
- Print server
- Collaboration
- WWW
- Modern ERP systems
- Instant messaging
- Revision control (CVS)
Data-Flow
- Also known as pipes-and-filters architecture
- Consists of a series of data transformations
- Examples:
- Unix text processing tools (wc, grep, sort, uniq, join)
- Netpbm graphics processing package
Create Manual Page Index
Object-Oriented
- Design is based on interacting objects
- Each object maintains its own state
- State is manipulated by methods
- Objects are typically grouped into classes
- Classes are often organised into generalisation relationships
A generalization relationship in the Tomcat servlet container
Layered
- Can organise multiple peer subsystems
- Each layer:
- Presents a standard interface to its upper layer
- Communicates using a different standard interface with its lower layer
- Essentially each layer implements a virtual machine
- Lower layers shall not use upper layers
- Examples:
- Network stacks
- Operating system structures
The Windows NT implementation layers
Hierarchies
Hierarchies
- provide structure
- facilitate navigation
- can be used orthogonally with other architectures
- examples
- directories
- DNS
- call graphs
- identifier namespaces
The NetBSD kernel source hierarchy
Control Models
- Call and return
- Structure prescribes control
- Flow of data
- Method invocation
- Event-Driven Systems
- System Manager
- State Transition
Event-Driven Systems
- Control decisions depend on external events
- Events can be broadcast to all listeners (e.g. power down)
- Events can be polled from a source (e.g. GetMessage)
- Handlers can be registered to respond
- Examples
- Hardware interrupts
- GUI systems
- Relational database triggers
- System and network management
System Manager
- Useful for orchestrating multiple (pseudo) concurrent processes
- One process acts as central manager
- Typical operations:
State Transition
- Changes in data (the state) direct the flow of control
- Often modelled as a state machine
- Set of states
- Initial state
- Final state
- Actions (processing and state transitions)
TCP state transition diagram
B: Element Packaging Approaches
Elements can be packaged using the following approaches:
- Module
- Namespace
- Object
- Generic implementation
- Abstract data type
- Library
- Component
- Process
- Data repository
Module
- Separately named and addressable component
- Provides services to other modules
- Typically interacts through procedure calls and data sharing
- Physical boundary is often a file
- Provides information hiding (only exposes what is needed)
Namespace
- Counters namespace pollution
- Unique prefix associated with a part of the implementation
- Supported by languages such as C++, C#, Java, Modula and Perl
Object
- Encapsulates data and code
- Fields contain data
- Methods contain code for acting on the data
- Every object has its own copy of the data
- Same objects are typically grouped into a class
- Classes can also contain data and code shared among all objects
- Classes can be organised in an inheritance hierarchy
- Each derived class inherits the fields and methods of its base class
- Polymorphism allows objects of any derived class to be used as objects of the base class
Generic Implementation
- Works with arbitrary data types
- Based on concepts a particular element must satisfy (e.g. comparable)
- Typically available as standardised library supporting e.g.
- Containers
- Iterators for traversing the containers
- Algorithms on containers
- Numeric algorithms
Abstract Data Type
- Encapsulates data
- Separates interface from implementation
- Implementation can change; interface remains
- Interface often specified in a formal manner
Examples
- Programming in the small:
- Programming in the large:
- Relational database accessible via stored procedures
- Data accessible via the web service model
Library
- Organized collection of modules
- Sharing a common purpose
- Typically distributed in binary form
- Uses:
- Facilitates code reuse
- Optimises the build process
- Load application features on demand (plugin)
Component
- Self contained unit of program composition
- Documented and well defined interfaces
- Deployed without access to the original developers
- Often distributed and used by third parties
- In common with objects
- Encapsulate state
- Provide access mechanisms through interfaces
- Support modular design
- In addition
- Can be implemented in different languages (although .NET allows this for objects as well)
- Robustly packaged in binary containers
- Can encapsulate multiple objects (e.g. DataGrid)
- Examples
Process
- Expensive startup and communication overhead
- Robust isolation (OS enforced)
- Faults (e.g. buffer overflow problems)
- Resources (e.g. open files)
- Privileges
- Simplifies build process and deployment
Data Repository
- Structure of the data reflects the structure of the system
- Examples
- Relational database
- Directory structure
- Windows registry
- XML data
C: Architectural Reuse
Reusing architectural designs is often more important than reusing code.
Some commonly-used approaches are:
- Frameworks
- Code wizards
- Design patterns
- Domain-specific and reference architectures
Framework
- Collection of classes serving a common goal
- Allow the expression of sophisticated architectures
- Designed to provide a reuse base for implementing complete systems
- Examples
- Adaptive Communication Environment
- Microsoft Foundation Classes
- Abstract Windowing Toolkit
Code Wizard
- Automatically generates (often cryptic) code
- User-guided
- Code is supposed to be subsequently modified
- Problematic if initially stated requirements change
Design Patterns
"Each pattern describes a problem which occurs over and over again in
our environment, and then describes the core of the solution to that
problem, in such a way that you can use this solution a million times over,
without ever doing it the same way twice."
- Christopher Alexander
- Describe concepts, not code
- Finer-grained than frameworks
- Typical description
- a pattern name such as Singleton or Reactor used to identify the pattern,
- an illustration of its structure using a UML diagram,
- a classification of the pattern as e.g. creational, behavioural, or structural,
- an illustration of the design problem that provides the motivation to use the pattern,
- an outline of the situations where the pattern can be applied,
- an outline of the pattern's participants,
- a description of how the pattern supports its objectives, and
- examples and prescriptive guidelines towards the pattern's implementation.
Domain-Specific and Reference Architectures
- Some application classes are typically associated with a specific architecture
- Other architectures are abstract and refer to a given field
- Examples
- Compilers
- Operating systems
- OSI reference architecture
- Web services architecture
D: Web Services Architecture
Web Service
- Instance of Service Oriented Architecture
- Software system designed to support interoperable networked machine-to-machine interaction
- Interface described in a machine-processable format (WSDL)
- Interaction through SOAP messages
- Conveyed using HTTP with an XML serialization
Web Services Architecture
- Standard means of interoperating between different software applications
- Applications can run on a variety of platforms and/or frameworks
- Interoperability through the definition of compatible protocols
Roles of Humans and Machines
Web Service Technologies
WSA Models
- Message Oriented Model (e.g. message structure)
- Service Oriented Model (e.g. services and related actions)
- Resource Oriented Model (identification of resources)
- Policy Model (constraints like security and QoS)
- Management Model (relationship of deployed elements)
Message Oriented Model
Important Definitions
- Correlation is the association of a message with a context. Message correlation ensures that the agent requesting a service execution can match the reply with the request, especially when multiple replies may be possible.
- A message is the basic unit of data sent from one software agent to another in the context of Web services.
- A message envelope is that meta-data associated with a message that permits the message to be delivered, intact.
- A Message Exchanage Pattern (MEP) is a template, devoid of application semantics, that describes a generic pattern for the exchange of messages between agents.
Service Oriented Model
Important Definitions
-
An action, for the purposes of this architecture, is any action that may be performed by an agent as a result of receiving a message, or results in sending a message or other observable state change.
-
A choreography defines the sequence and conditions under which multiple cooperating independent Web services exchange information in order to achieve some useful function.
-
A service is a set of actions that form a coherent whole from the point of view of service providers and service requesters.
-
The semantics of a service is the contract between the service provider and the service requester that expresses the effect of invoking the service. A service semantics may be formally described in a machine readable form, identified but not formally defined or informally defined via an `out of band' agreement between the provider and the requester.
-
A service task is a unit of activity associated with a service. It is denoted by a pair: a goal and an action; the goal denotes the intended effect of the task and the action denotes the process by which the goal is achieved.
Resource Oriented Model
Important Definitions
-
Discovery is the act of locating a machine-processable description of a Web service that may have been previously unknown and that meets certain functional criteria.
A discovery service is a service that performs the above discovery; of particular interest are discovery services that permit the discovery of Web services.
Policy Model
Important Definitions
-
An audit guard is a mechanism deployed on behalf of an owner that monitors actions and agents to verify the satisfaction of obligations.
-
A permission guard is a mechanism deployed on behalf of an owner that enforces permission policies.
-
A policy is a constraint on the behaviour of agents.
-
A policy guard is a mechanism deployed on behalf of an owner that enforces a policy (or set of policies).
Management Model
Important Definitions
-
A deployed resource is a resource that exists in the physical world. There are many kinds of deployed elements, including agents, services and descriptions.
-
A management configuration is a collection of properties of a manageable elements which may be changed.
-
Events are changes in the state of a manageable element that are relevant to the element's manager.
Bibliography
- L. Barroca, J. Hall, and
P. Hall, editors.
Software Architectures: Advances and Applications.
Springer Verlag, 1999.
- Grady Booch, James
Rumbaugh, and Ivar Jacobson.
The
Unified Modeling Language User Guide.
Addison-Wesley, Reading, MA, 1999.
- David Booth, Hugo Haas,
Francis McCabe, Eric Newcomer, Michael Champion, Chris Ferris, and David
Orchard.
Web services architecture (http://www.w3.org/TR/ws-arch/).
Available online http://www.w3.org/TR/ws-arch/, Aug 2003.
W3C Working Draft.
- L. L.
Constantine and E. Yourdon.
Structured Design.
Prentice Hall, 1979.
- James O. Coplien and
Douglas C. Schmidt.
Pattern Languages of Program Design.
Addison-Wesley, Reading, MA, 1995.
- Alan M. Davis.
201
Principles of Software Development, pages 73–99.
McGraw-Hill, 1995.
- Peter
Duchessi and InduShobha Chengalur-Smith.
Client/server benefits, problems, best practices.
Communications of the ACM, 41(5):87–94, May 1998.
- M. Fayad, R. Johnson,
and D. C. Schmidt, editors.
Domain-Specific Application Frameworks: Applications and
Experiences.
John Wiley and Sons, New York, 1999.
- M. Fayad, R. Johnson,
and D. C. Schmidt, editors.
Domain-Specific Application Frameworks: Problems and Perspectives.
John Wiley and Sons, New York, 1999.
- Institute of Electrical and
Electronics Engineers, Inc., New York, NY, USA.
IEEE Recommended Practice for Software Design Descriptions, 1998.
IEEE Standard 1016-1998.
- Institute of Electrical and
Electronics Engineers, Inc., New York, NY, USA.
IEEE Recommended Practice for Architectural Description of Software
Incentive Systems, 2000.
IEEE Standard 1471-2000.
- Brian W. Kernighan
and Rob Pike.
The
UNIX Programming Environment.
Prentice-Hall, Englewood Cliffs, NJ, 1984.
- Scott M. Lewandowski.
Frameworks for component-based client/server computing.
ACM Computing Surveys, 30(1):3–27, March 1998.
- David G.
Messerschmitt and Clemens Szyperski.
Software Ecosystem—Understanding An Indispensable Technology and
Industry.
MIT Press, Cambridge, 2003.
- Object
Management Group, Inc.
The common object request broker: Architecture and specification, July 1996.
Revision 2.0 (Updated).
- Roger S. Pressman.
Software Engineering: A Practitioner's Approach, pages 330–393.
McGraw-Hill, fifth edition, 2000.
European Adaptation. Adapted by Darrel Ince.
- Konstantinos Raptis,
Diomidis Spinellis, and Sokratis Katsikas.
Multi-technology distributed objects and their integration ( http://www.spinellis.gr/pubs/jrnl/2001-CSI-Components/html/imtd.html).
Computer Standards & Interfaces, 23:157–168, July 2001.
- J. H. Saltzer, D. P.
Reed, and D. D. Clark.
End-to-end arguments in system design.
ACM Transactions on Computer Systems, 2(4):277–288, November
1984.
- Mary Shaw and David
Garlan.
Formulations and Formalisms in Software Architecture.
Springer Verlag, 1995.
Lecture Notes in Computer Science 1000.
- J. Siegel.
A preview of CORBA 3.
Computer, 32(5):114–116, May 1999.
- Ian Sommerville.
Software Engineering, pages 215–259.
Addison-Wesley, sixth edition, 2001.
- Diomidis Spinellis.
The computer's new clothes ( http://www.spinellis.gr/pubs/jrnl/1998-IEEESoft-CliServ/html/CliServ.html).
IEEE Software, 15(6):14–17, November/December 1998.
- Diomidis Spinellis.
Code Reading: The Open
Source Perspective, chapter 9, pages 267–338.
Effective Software Development Series. Addison-Wesley, Boston, MA, 2003.
- Sun
Microsystems Inc.
Java remote
method invocation specification.
Available online http://java.sun.com/docs/guide/rmi/spec/rmiTOC.html/ (February
2002), December 1999.
Revision 1.7, Java 2 SDK, Standard Edition, v1.3.0.
- Clemens Szyperski.
Component Software: Behind Object-Oriented Programming.
Addison-Wesley, Reading, MA, second edition, 2002.
- Damien Watkins, Mark
Hammond, and Brad Abrams.
Programming in the .NET Environment.
Addison-Wesley, Reading, MA, 2002.
Database systems
Advantages
- Data independence
- Efficient data access
- Data integrity
- Data security
- Data administration capabilities
- Resilient concurrent access
- Crash recovery
- Reduced application development time
Problems and Limitations
- Data Management approach poses problems in data resource management
- Developing a large database and installing a DBMS can be difficult and expensive
- More hardware capability is required (storage and memory requirements are higher)
- Longer processing times may result from high-volume transaction processing applications
- The security and integrity of an organization's databases are major concerns of an organization's data resource management effort
Levels of Abstraction
- Physical schema
- Defines how data is stored
- Conceptual schema or logical schema
- Defines data in terms of a data model
- External schema or view level
- Defines a number of simplified domain-specific views
DBMS Levels of Abstraction
Data Independence
The three different levels of abstraction allow us to:
- Change the file organization without affecting the conceptual schema
- Change the conceptual schema without affecting an application (by adjusting the external schema)
Database Design
- Requirements analysis
- Conceptual database design: develop high level description
- Logical database design: map description into the specific DBMS
- Schema refinement: identify and solve potential problems
- Physical database design: optimize for specific workloads
- Security design
Entities and Attributes
- Entity
- Object in the real world
- Attributes
- Describe each entity
- Entity set
- Group of similar entities (share same attributes)
- Attribute domain
- Values that can be used for the attribute
- Key
- Minimal set of attributes that uniquely identify an entity
- Primary key
- Designated among a number of candidate keys
The books entity set
The Entity Relationship Model
- Relationship
- Association between two entities
- Relationship set
- Group of similar relationships
- Descriptive attributes
- can identify a relationsip
A relationship can be identified as:
- one-to-many
- many-to-many
- one-to-one
The Published relationship
The Relational Model
Relation Schema
- Name of the relation
- Name of each field (or column or attribute)
- Domain of each field
Relation Instance
- Set of tuples (or records)
(Table of rows with the same number of fields)
ISBN | Title | Price |
0-387-02620-7 | Beyond Fear | 29.00 |
0-201-79940-5 | Code Reading | 49.95 |
0-07-246535-2 | Database Management Systems | 40.00 |
0-19-502402-8 | The Timeless Way of Building | 60.00 |
Redundancy
Storing redundant information in a database results in:
- Waste of space
- Data that may not be correctly updated
- Data that can not be inserted unless other data is also inserted
- Data that is incidentally lost when other data is removed
Example
ISBN | Title | Price | Discount | Reduced Price |
0-387-02620-7 | Beyond Fear | 30.00 | 10 | 27.00 |
0-201-79940-5 | Code Reading | 50.00 | 20 | 40.00 |
0-07-246535-2 | Database Management Systems | 40.00 | 20 | 38.00 |
0-19-502402-8 | The Timeless Way of Building | 60.00 | 10 | 54.00 |
Dependencies are resolved by decomposing the relations.
The Structured Query Language
Language used for
- Creating
- Manipulating
- Querying
relational DBMSs.
Used:
- Directly by database administrators and expert users
- As a standard way for applications to communicate with the DBMS
- As a way to backup, restore, and transfer data in a portable form
SQL Table Definition and Data Manipulation
Create the Table
CREATE TABLE Books (
isbn CHAR(13),
title CHAR(100),
price real)
Add a Record
INSERT
INTO Books (isbn, title, price)
VALUES ("0-201-79940-5", "Code Reading", 49.95)
Modify Records
UPDATE Books B
SET B.price = B.price * 1.1
Delete a Record
DELETE
FROM Books B
WHERE ISBN="0-201-79940-5"
SQL Queries
Display the Details for a Record
SELECT *
FROM Books
WHERE ISBN="0-201-79940-5"
Display Records Based on a Condition
SELECT title, price
FROM Books
WHERE price > 50 AND price > 10
Perform an Aggregate Calculation
SELECT AVG(price)
FROM Books
Join Two Tables
SELECT title, authorname
FROM Books, Authors
WHERE Books.authorid = Authors.authorid
Query By Example
SELECT BOOKS.title, BOOKS.price, BOOKS.price, BOOKS.isbn
FROM BOOKS
WHERE (((BOOKS.price)>100)) OR (((BOOKS.price)<10))
ORDER BY BOOKS.title;
Additional SQL Query Constructs
SQL provides many sophisticated capabilities:
- Selection of distinct records
SELECT DISTINCT title, price
FROM Books
WHERE price < 50 AND price > 10
- Aggregate calculations (COUNT, SUM, AVG, MIN, MAX)
SELECT MIN(price), MAX(price)
FROM Books
- Operations on groups
SELECT discount, AVG(price)
FROM Books
WHERE price > 10
GROUP BY discount
HAVING MAX(price) - MIN(price) > 10
- String pattern matching
SELECT title, price
FROM Books
WHERE title LIKE 'TIMELESS%'
- Ordering
SELECT title, price
FROM Books
ORDER BY price
- Set union, intersection and difference (UNION, INTERSECT, EXCEPT)
SELECT title, price
FROM Books
UNION
SELECT title, price
FROM magazines
- Nested queries (IN, EXISTS, operator ANY, operator ALL)
SELECT title, price
FROM Books
WHERE price > (SELECT AVG(price) FROM Books)
SELECT title, price
FROM Books
WHERE price < ALL
(SELECT price
FROM Books
WHERE title LIKE 'Harry Potter%')
Views
By defining appropriate views on a schema we
- Achieve logical data independance
- Can better organise security
CREATE VIEW BrowseBooks(isbn, title)
AS SELECT B.isbn, B.title
FROM Books B
WHERE B.price < 100
Indexes
An index is an auxilliary data structure used
to speed up operations that are not efficiently supported by
a table's record organisation.
CREATE INDEX IndPrice ON Books
WITH STRUCTURE = BTREE
KEY = (price)
To design the index structure take into account:
- The query workload
- The update (insert, delete, update) workload
- Operations that will benefit from the index
- Attributes that are often used
- The type of the index structure (hash versus tree)
- Index maintenance cost
Security Issues
Our goal in designing a secure database is to achieve:
- Confidentiality
- Integrity
- Availability
Discretionary access control provides us the capability
to give (and revoke) rights to specific users or groups.
Examples
GRANT SELECT
ON BrowseBooks
TO WebUsers
REVOKE INSERT, DELETE
ON Books
From Alice
GRANT INSERT, DELETE
ON Books
TO InventoryGroup
GRANT UPDATE(price)
ON Books
TO MarketingGroup
GRANT UPDATE(title, isbn)
ON Books
TO MaintenanceGroup
Transaction Management
- A transaction is a single unit of execution program execution (e.g. book a seat)
- Transactions provide concurrency control
- Transactions support crash recovery
Four important properties (ACID):
- Atomic
- Database ensures that all actions are carried out, or none
- Consistency
- Users ensure that transactions leave the data in a consistent state
- Isolation
- Users to not have to worry about concurrently executing transactions
- Durability
- Completed transactions persist after a crash even if the database has not been updated
Crash Recovery
- Crash recovery mechanisms guard against
- System crashes
- Media failures
- A log or journal records all changes before they modify the database
- The log is assumed to survive system crashes and media failures
- After a crash the recovery manager follows the ARIES stretegy
- Analysis
- of changes that have not been written and active transactions
- Redo
- actions that were not written to the database
- Undo
- transactions that were not completed
- The log is also updated during the recovery to guard against repeated crashes
- A checkpoint is periodically recorded to the log to reduce the recovery overhead
- A checkpointing strategy is also used to take backup copies of live databases
The Database Administrator
Coordinates all the activities of the database system; the database administrator has a good understanding of the enterprise's information resources and needs.
The database administrator's duties include:
- Schema definition
- Storage structure and access method definition
- Schema and physical organization modification
- Granting user authority to access the database
- Specifying integrity constraints
- Acting as liaison with users
- Monitoring performance and responding to changes in requirements
User Profiles
Users are differentiated by the way they expect to interact with the system
- Application programmers
- interact with system through DML calls
- Sophisticated users
- form requests in a database query language
- Specialized users
- write specialized database applications that do not fit into the traditional data processing framework
- Naive users
- invoke one of the permanent application programs that have been written previously
RAID Storage
Redundant arrays of independent disks (RAID) are used to overcome
two bottlenecks associated with disk storage:
By using additional redundant disks we can increase both.
The following are some typically identified RAID levels:
- 0: Nonredundant
- Data is distributed across different disks to increase performance
- 1: Mirrored
- A second disk set keeps a copy of the data (50% overhead)
- 0+1 (or 10): Striping and mirroring
- Data is distributed across a second disk set to increase performance
- 2: Error correcting codes
- Additional check disks (4:3, 10:4, 25:5) are used to provide redundancy
with a smaller overhead (e.g. 57%, 71%, 83%)
- 3: Bit-interleaved parity
- A single additional check disk is used to recover the data by distributing bits across all disks
- 4: block-interleaved parity
- The check disk contains the parity on a block level: higher read throughput
- 5: block-interleaved distributed parity
- Block parity is distributed across all disks: higher read and write throughput
- 6: higher redundancy
- Like 5 with an additional check disk guarding against a second failure
XML Concepts
- Semantic and structural text markup language
- Does not (directly) define presentation
- Application of SGML derived from HTML
- Extensible
- A separate document type definition is used to specify the structure of the data
- Delivers cross-platform data portability
- Domain-specific applications allow data interchange
XML Syntax
An XML document is structured on the following building blocks:
- Elements
- Delimited by starting and ending tags
Example:
<title>The Lord of the Rings</title>
Elements can also be empty; a special shortcut makes them smaller:
Example:
<dvd></dvd>
is the same as
<dvd />
- Attributes
- Name=valua pairs in the starting tag, that can be used for metadata
Example:
<title lang="english">The Lord of the Rings</title>
- Entity references
- Are used to refer to special (reserved) symbols
Symbol | Entity reference |
< | < |
> | > |
& | & |
" | " |
' | ' |
- Comments
- Delimited by the <!-- and -> sequence
Example:
<!-- this is a comment ->
Example
<!-- List of shipped books -->
<booklist>
<book>
<isbn>0-387-02620-7</isbn>
<title>Beyond Fear</title>
<author>
<givenname>Bruce</givenname>
<familyname>Schneier</familyname>
</author>
<price>30.00</price>
</book>
<book>
<isbn>0-201-79940-5</isbn>
<title>Code Reading</title>
<author>
<givenname>Diomidis</givenname>
<familyname>Spinellis</familyname>
</author>
<price>50.00</price>
</book>
<book>
<isbn>0-07-246535-2</isbn>
<title>Database Management Systems</title>
<author>
<givenname>Raghu</givenname>
<familyname>Ramakrishnan</familyname>
</author>
<author>
<givenname>Johannes</givenname>
<familyname>Gehrke</familyname>
</author>
<price>40.00</price>
</book>
<book>
<isbn>0-19-502402-8</isbn>
<title>The Timeless Way of Building</title>
<author>
<givenname>Cristopher</givenname>
<familyname>Alexander</familyname>
</author>
<price>60.00</price>
</book>
<book>
<isbn>3-8218-0479-3</isbn>
<title lang="german">Lexikon der Populaeren Irrtuemer</title>
<author>
<givenname>Walter</givenname>
<familyname>Kraemer</familyname>
</author>
<author>
<givenname>Goetz</givenname>
<familyname>Trenkler</familyname>
</author>
<price>40.00</price>
</book>
</booklist>
Document Type Definitions
- A document type definition is used to describe the format of valid XML documents
- It can be used to verify XML documents
- It can be used to parse XML documents decomposing them into a tree
- Defines allowed elements
- For each element defines content and supported attributes
- Specified element content can be
- Parsed character data
- Indicated by #PCDATA
- Child element
- Indicated (name)
- Sequence of elements
- Indicated by (child1, child2, ...)
- Zero or one child elements
- Indicated by name?
- Zero or more child elements
- Indicated by name*
- One or more child elements
- Indicated by name+
- A choice among different child elements
- Indicated by (name1 | name2 | ...)
Example:
<!ELEMENT booklist (book)*>
<!ELEMENT book (isbn,title,author+,price,edition?)*>
<!ELEMENT isbn (#PCDATA)>
<!ELEMENT title (#PCDATA)>
<!ATTLIST title lang (german|english) "german">
<!ELEMENT author (givenname,familyname)>
<!ELEMENT givenname (#PCDATA)*>
<!ELEMENT familyname (#PCDATA)>
<!ELEMENT price (#PCDATA)>
<!ELEMENT edition (#PCDATA)>
Bibliography
- D. D. Chamberlin,
M. M. Astrahan, K. P. Eswaran, P. P. Griffiths, R. A. Lorie, J. W. Mehl,
P. Reisner, and B. W. Wade.
SEQUEL 2: A unified approach to data definition manipulation and control.
IBM Journal of Research and Development, 20(6):560-575, November
1976.
- Peter Pin-Shan Chen.
The entity-relationship model --- toward a unified view of data.
ACM Transactions on Database Systems, 1(1):9-36, March 1976.
- Elliotte Rusty Harold
and W. Scott Means.
XML
in a Nutshell.
O'Reilly and Associates, Sebastopol, CA, 2001.
- International Organization
for Standardization, Geneva, Switzerland.
Information technology --- Database languages --- SQL, 1992.
ISO/IEC 9075:1992.
- Henry F. Korth
and Abraham Silberschatz.
Database System Concepts.
McGraw-Hill, second edition, 1991.
- Raghu
Ramakrishnan and Johannes Gehrke.
Database Management Systems.
McGraw-Hill, second edition, 2000.
System administration
Client Workstations
Main tasks:
- Installation
- Operating system
- Applications
- Policy configuration
- Maxims
- Automate
- Avoid pre-installed systems
- Update operating system and applications
- Configure network settings (DHCP)
Servers
Important elements:
- Hardware
- Internal expansion space
- Upgrade path
- Input and output
- Rack mounting
- Exclusive front access
- Hot swapping
- RAID storage
- Maintenance policy
- Active backup plan
- Installation at the computer centre
- Specialised software
- Remote access
- Separation of operational network from the administration network
Rack-mounted servers
Services
Basic principles:
- Open architecture
- Distinguish products vs protocols
- Provision the service independently from the server (e.g. mail.company.gr)
- Insist on locating the service in the computing centre
- Protected power
- Cooling and humidity control
- Fire suppression
- Physical security
- Network capacity
- Can have multiple servers for the same service
- Need mechanism for service monitoring
- Expand or organise into one server for each service
Debugging Techniques
Basic strategy:
- Understand problem
- Find the problem's cause (not the symptom)
- Fix the problem
- Use appropriate tools
Two basic techniques:
- Successive elimination of possible causes (e.g. removing drivers)
- Successive refinement of possible causes (e.g. traceroute)
Tool examples:
- ping
- traceroute / tracert
- nslookup
- strace / truss / apispy
- grep / locate / regedit
- "Use the source Luke"
The Fix-Once Principle
- Fix the problem, not the symptom
- ... for ever ...
- ... without re-inventing the wheel ...
- ... on all hosts ...
- Automation plays a key role in satisfying the above
Namespaces
Namespaces:
- Users
- Hosts
- Network addresses
- Files
- User groups
Naming policies:
- Name types
- Formulaic (e.g. pc01, pc02, dspin, gvour, ptsah, gpap02)
- Thematic (e.g. thira, naxos, paros, kriti, thasos, samos, ithaki)
- Functional (e.g. finance, admin, guest)
- Free; first come first served
- Longevity policy (when are entries removed?)
- Scope policy (where is this namespace to be used? - in terms of geography and services)
Management policy:
- Adding new names
- Changing names
- Removing names
- All the above should preferably be centralised
Disaster Planning and Recovery
Disaster types
- Acts of god (e.g. earthquake, fire, flood)
- Human (e.g. power loss, terrorist act, bulldozer)
budget = disaster cost * disaster probability
Actions:
- Minimize possibility of damage (e.g. using rack-mounted components makes
servers less susceptible to earthquake damage,
an uninterruptible power supply (UPS) will guard against power fluctuations)
- Preparedness
- Disaster recovery plan
- Backup data centre
Change Management
Basic principles:
- Use version control tools (e.g. CVS, RCS)
- Keep a detailed change log
- Run regression changing after each change
- Notify affected parties before and after the change
RCS Log Example
RCS file: RCS/ppp.conf,v
Working file: ppp.conf
head: 1.10
branch:
locks: strict
dds: 1.10
access list:
symbolic names:
keyword substitution: kv
total revisions: 10; selected revisions: 10
description:
----------------------------
revision 1.10 locked by: dds;
date: 2002/01/21 09:27:15; author: dds; state: Exp; lines: +5 -0
Added CVS pserver rule.
----------------------------
revision 1.9
date: 2001/12/21 07:47:57; author: dds; state: Exp; lines: +3 -3
New phone numbers.
----------------------------
revision 1.8
date: 2001/12/13 07:46:12; author: dds; state: Exp; lines: +6 -5
Disable multilink.
Allow NTP packets.
----------------------------
revision 1.7
date: 2001/11/22 14:44:25; author: dds; state: Exp; lines: +20 -4
Added aueb connection support.
Fixed to work with outgoing ping.
Added missing traceroute roules.
----------------------------
revision 1.6
date: 2001/11/06 19:23:33; author: dds; state: Exp; lines: +16 -6
Blocked SNMP
Contrained application-level data
Fixed cddb.
----------------------------
revision 1.5
date: 2001/11/06 19:22:24; author: dds; state: Exp; lines: +17 -7
Added CDDB, application lelvel data, ...
----------------------------
revision 1.4
date: 2001/02/04 15:04:18; author: dds; state: Exp; lines: +1 -2
Timeout to 2.5 minutes.
----------------------------
revision 1.3
date: 2001/02/03 11:16:06; author: dds; state: Exp; lines: +1 -1
Do not enable DNS, we have our own.
----------------------------
revision 1.2
date: 2001/01/30 23:11:48; author: dds; state: Exp; lines: +168 -11
Added hosts and filters.
----------------------------
revision 1.1
date: 2001/01/20 19:26:15; author: dds; state: Exp;
Initial revision
----------------------------
=============================================================================
Manual Change Log Example
Thu Dec 04 14:20:52 EST 2003
To correct wireless dhcp problems download and install fix KB826942
Tue Dec 24 10:16:13 EET 2002
Enable time serving for Windows clients in smb.conf
time server = True
From Windows execute: net time /set
Thu Dec 5 09:24:38 EET 2002
build kernels
run mergemaster
make installkernel KERNCONF=SPITI
cp /vol/obj/vol/src/sys/OFFICE/kernel /usr/export/boot
Wed Dec 4 15:15:08 EET 2002
In /usr/src run build and install
co /sys/dev/ata/ata-disk.c
rebuild kernel
Mon Dec 2 12:50:17 EET 2002
In /vol/ports/databases/p5-DBD-SQLite/work/DBD-SQLite-0.21
run perl getsqlite.pl 2.7.3 after manually downloading the file)
After that make, make install
Thu Nov 28 10:02:53 EET 2002
pkg_delete newt-0.50.13 dhcpconf-0.7.0
pkg_delete tcl-8.2.3
make install in /vol/ports/databases/sqlite
(also installed tcl-8.3.5)
Sun Nov 17 13:21:29 EET 2002
Run cvsup -g -L 2 -z supfile
Run cvsup -g -L 2 -z ports-supfile
Install ports/p5-DBI
Install ports/p5-DBD-SQLite
Upgrades
Server upgrade procedure:
- Existing services
- Services offered by the server
- Service users
- Software offering the services
- Ensure each software element works in the new release
- Plan testing procedure for each service
- Create back-out plan
- Choose maintenance interval
- Notify users
- Run test plan on existing server
- Upgrade (with an assistant)
- Repeat tests
- If tests fail follow back-out plan
- Notify customers
Upgrading TAXISnet
Centralising and Decentralising
We often must decide for or against central or distributed approaches.
The following facts can aid our decision:
- Reasons to move towards a direction
- Problem we want to solve
- Try to centrally manage as many elements as realistically possible
- Increasing centralisation increases the need for handling special cases
- Once a technology becomes widely adopted it also becomes a target for
centralised management
- A move towards centralised management is like any other change or upgrade, but
- ... it offers us a unique chance to make a good impression
- Listen to customer concerns, but remember that IT should have the last word
Centralised management candidates:
- Distributed systems
- Consolidate services on less machines
- System administration
- Infrastructure decisions
- Procurement
- Support
The Helpdesk Service
To plan a helpdesk service you need to consider:
- What is being supported?
- Who is being supported?
- When is support being provided?
- Where is support being provided?
- What is the expected response time?
An important element of a helpdesk service is an information system that
provides the following functionality:
- Registering new requests
- Assigning a ticket to each request
- Informs management and customers on the progress of each request
- Supports an issue lifecycle
- Allows searching for issues using various criteria
Example of a Problem Entry Form (Bugzilla)
Search Form
Search Results
Bug #
|
Dupe Count
|
Change in last 7 day(s)
|
Component
|
Severity
|
Op Sys
|
Target Milestone
|
Summary
|
22274
|
126
|
0 |
Layout |
normal |
All |
--- |
[INLINE] Too much space (for descenders) under image elements |
20618
|
98
|
0 |
Browser-General |
major |
Windows 98 |
--- |
Mousewheel doesn't work with some driver/Win32 OS combinations (scroll, scrolling) |
195600
|
88
|
0 |
Installer |
critical |
Windows 2000 |
--- |
browser crashes on startup after install and after xpi install. Installation of 1.4 fails |
25537
|
83
|
0 |
Layout |
enhancement |
All |
--- |
alt text is not displayed as a tooltip |
38488
|
71
|
0 |
Networking: HTTP |
major |
All |
--- |
Proxy:junkbuster is broken - use http/1.0 to get arround this |
28586
|
62
|
0 |
Embedding: Docshell |
enhancement |
All |
Future |
meta bug - show error pages instead of dialogs for network errors (placeholder page in the content area) (http error pages) |
11459
|
62
|
0 |
Preferences |
normal |
All |
--- |
need option for mailto: to launch external mail app or open a webmail url |
105547
|
62
|
0 |
Tabbed Browser |
normal |
All |
--- |
Windows open in new window instead of tabs (target=<nonexistant_frame>) |
69938
|
59
|
0 |
File Handling |
critical |
All |
Future |
Downloads are stored in $TMPDIR|$TMP|$TEMP|/tmp first and moved to the selected path after the download finishes |
94035
|
58
|
1 |
Plug-ins |
enhancement |
All |
Future |
Allow blocking of any media type (flash, plug-in, applet, etc.) by site (like cookies and images) |
193638
|
58
|
0 |
Preferences: Backend |
normal |
All |
--- |
corrupt or lost pref.js / startup configuration error |
167663
|
55
|
0 |
XP Apps |
critical |
MacOS X |
mozilla1.0.2 |
[OS X]window disappears when clicking the maximize button (green +) |
104532
|
53
|
1 |
Tabbed Browser |
normal |
All |
--- |
Status bar ticker fails to update when tabs switched. |
Customer Support
The steps:
- Greeting
- Learn about the problem
- Reproduce the problem and agree with the customer
- Try the problem
- Locate problem resolution proposals
- Select solution
- Execute solution
- Verify solution
- Agree with customer that problem has been solved
The problem life cycle
Organising the Data Centre
- Physical access and security
- Rack-mounting
- Fire protection
- Natural disaster protection
- Network provisioning
- Raised floor (strong + ramp access)
- Power supply (emergency cuto-off)
- Air conditioning
- Temperature, access, and power monitoring
- Labeling
- Tools
- Workbench
- Storage space
- Cart
/>
Data center
Seen outside a data centre:
ACHTUNG!!!
Das machine is nicht fur gefingerpoken und mittengrabben. Ist easy
schnappen der springenwerk, blowenfusen und corkenpoppen mit
spitzensparken. Ist nicht fur gewerken by das dummkopfen. Das
rubbernecken sightseeren keepen hands in das pockets. Relaxen und
vatch das blinkenlights!!!
|
Network Management
Possible network topologies:
- Flat (all elements are at the same level-3)
- According to the physical layout of equipment
- According to functional requirements
- An important element is the "intermediate distribution frame (IDF)
- Termination point for all floor's machines
- Label each frame with building, floor, and serial number
- Label each connection with room number and jack identifier
- Example 1/4/2/12A: building 1, floor 4, frame 2, room 12, jack A
In large buildings a main distribution frame (MDF),
often located at the data centre,
acts as a central hub.
Basic principles:
- Simple architecture
- Reliable implementation
- Labeling and documentation
- Use the best wiring you can afford
- UPS at the distribution frames
- Consistently locate IDFs on each floor
- Use clear demarcation points for network providers
- Utilise open protocols (IETF, IEEE)
- Adopt simple routing
- Use specialised routers (not general-purpose computers)
- Minimise number of vendors
- Avoid bleeding-edge technology
Distribution frame. On the bottom one can see the UPS units.
Email Services
Functional units
- Transfer
- Delivery
- Mailing lists
Basic operational principles:
- Simple architecture based on open standard protocols (SMTP, IMAP, POP)
- Proper consistent naming and management
- Service monitoring (postmaster account)
- Personal data protection policy
- Security
- User education
- Spam and virus handling
Backups
Backup copies are required when:
- Data is (accidentally) deleted
- The main storage medium fails
- As a corporate data repository
To optimise the backup process we can distinguish the following
types of backup:
- Full backup (contains a complete copy of the data - also called level-0)
- Incremental backup (often multiple levels - also called level-n)
Every level contains differences from previous level.
Ensure that:
- Backup copies are stored in a different, but safe location (off-site)
- Periodically the ability to recover a single file or a complete disk is verified
References
Discussion Topics
- Outline the services offered by your organisation's (or the University's)
data centre
- Provide an example where the symptom, rather than the cause is corrected
- Describe the naming policy and the management procedures for the
.gr domain
Software development
The Software Development Process
A software process defines the following practices:
- acquisition
- implementation
- maintenance
- retirement
of software-intensive products and services.
It can be divided into three phases:
- Project definition (what?)
- Implementation (how?)
- Support (change)
A process also defines a number of cross-cutting areas:
- Testing
- Technical reviews
- Quality assurance
- Configuration management
- Documentation
- Reuse
- Metrics
- Risk management
Process Maturity
CMU's Software Engineering Institute has defined the following process
maturity levels:
- Initial
- Repeatable
- Defined
- Managed
- Optimising
Every level encompasses the elements of the previous one.
Software Process Models
Some well-known process models include the following:
- Waterfall model (mainly of historical interest)
- Spiral development. Involves cycles of
- Customer negotiation
- Design
- Risk analysis
- Implementation
- Measurements
- Evaluation
Successive iterations can involve
- Prototype
- New product
- Improved product
- Maintenance cycles
- Rapid application development (based on business/data/process modelling and 4GL implementation)
- Incremental refinement
- Prototype-based (of e.g. user interface, functionality, or algorithms)
Requirement Types
Product / process
- Product requirements
- process requirements
Product Requirements
- Functional requirements
- Non-functional requirements
Levels of Detail
- User requirements, targeting
- customer administrative personnel
- contractor administrative personnel
- end users
- customer engineers
- system architects
- System requirements, targeting
- end users
- customer engineers
- system architects
- contractor programmers
- Software design specification, targeting
- customer engineers (possibly)
- system architects
- contractor programmers
Requirement Drivers
Main specification drivers are:
- High level business goals
- Operating environment
- Management environment
Specifications are also affected by:
- End-users
- Customers
- Regulatory bodies
- Development engineers
Elicitation Techniques
- Interviews
- Scenarios
- Prototype development
- Structured meetings
- Observation
- Existing internal and external documentation
Non-functional Requirements
Product requirements
- usability
- efficiency
- reliability
- portability
Process requirements
- delivery
- implementation
- standards compliance
External requirements
- interoperability
- ethical requirements
- legislative
Non-functional Requirement Metrics
- Time
- Transactions / sec
- Response time
- Time to complete an operation
- Space
- Main memory
- Auxiliary memory
- (Cache)
- Usability
- Training time
- Number of choices
- Mouse clicks
- Reliability
- Mean time to failure
- Downtime probability
- Failure rate
- Availability
- Robustness
- Time to recovery
- % of incidents leading to catastrophic failures
- Data corruption probability after a failure
- Portability
- % of non-portable code
- Number of systems where software can run
Requirement Management
- Requirement identification (e.g. numbering)
- Change management
- Traceability
- Requirement source
- Requirement dependencies
- Design mapping
- Support tools
Advantages of Prototype Development
Prototypes help in
- requirement elicitation
- requirement validation
- bridging communication gap between developers and end-users
- demonstrating a working system
- user training
- testing the final system (parallel testing)
In research examining 39 projects involving prototype development managers
gave as advantages:
- a more usable final system
- better end-user requirement matching
- higher quality design
- easier maintenance
- lower development cost
Prototype Development Techniques
- High-level languages
- 4GLs
- Component based development
- GUI editors
The Visual Basic programming environment
Implementation Guidelines
- Automate
- Refactor often
- Use existing libraries and components
- Express complex structures using data
static const int month_days[2][12] = {
{ 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 },
{ 31, 29, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 }
};
- Do not patch bad code; rewrite it
- Use recursive procedures for recursive structures
- When correcting an error look for similar ones
- Comments should not repeat the code
- Avoid clever tricks
- The code should mainly target people
- Use efficient data structures and algorithms
- Target correctness before efficiency
- Write the comments before the code
- Adopt a structured style even when using an unstructured language
- Use a programming language appropriate for the application you are building
- Employ assertions
- Write self checking code
- Adopt and follow a programming style
(after Kernighan and Plauger 1976, Davis 1995)
Development Tools
- Modelling and design tools
- Editors
- Interpreters and optimising compilers
- Code generators
- Debuggers
- Execution profilers
- Code browsers
- Help systems
- Test frameworks
- Configuration management systems
- Integrated development environments (IDEs)
- Tool workbenches
The vim editor
An application wizard
A debugger environment
The Java class documentation
Domain-specific Languages
- Target a specific problem domain
- Examples
- Efficiently capture the application's logic
- Lower the semantic distance between the problem and the program
Reuse Methods
- Process reuse
- Design patterns
- Component-based programming
- Domain-specific libraries
- Generic libraries
- Application frameworks
Reuse: the Pros and Cons
Pros
- Increased reliability
- Fewer development risks
- Capitalise on expert skills
- Adopt standards
- Decrease development time
Cons
- Application maintenance
- Long term reused code maintenance
- Tool support
- Not invented here syndrome
- Searching, evaluating, and adopting reused code
Optimisation
Optimise only when:
- The program is really slow
- The optimised program will continue to be correct
- The optimised program will continue to be readable
- The optimised program will continue to be reliable (cf buffer checks)
Common techniques:
- Use more efficient data structures and algorithms
- Execution profile; focus on hot spots
- Use a more efficient environment (e.g. move a 4GL into C++)
- Capitalise on the compiler's optimisations
- Optimise code
- Efficient use of hardware resources (parallelism)
- Avoid system calls
- Avoid the use of external data
- Save temporary results
- Pre-calculate results
Database Optimisation Techniques
- Use appropriate indexes
- Remove unneeded indexes
- Minimise data transfers from client to server
- Use SQL code instead of program loops
For example, the code:
Do While Not tblPersons.EOF
If tblPersons("Name") = looking Then
MsgBox "Your number is " & tblPersons("Number")
End If
tblPersons.MoveNext
Loop
could be replaces with:
Set qryPersons = dbsDb.OpenQuery("SELECT Number from Persons Where Name ='" & looking & "'")
Set rstPersons = qryPersons.OpenRecordset
If Not rstTables.EOF
MsgBox "Your number is " & rstPersons("Number")
End If
- Use tables with temporary data and triggers
- Use optimisation tools
Portability
Portability is hindered by:
- Different processors
- Different operating systems
- Different development tools and libraries
Porability can be enhanced by:
- Using only standard features
- Avoiding exotic and cutting edge features (even if standard)
- Avoiding undocumented features
- Not depending on binary formats and the host's byte order
- Using only standard or portable libraries
- Storing data in plain text files, possibly with XML markup
Internationalisation and Localisation
- Internationalisation
- Making software usable in different locales
- Localisation
- Adjusting the software for a given locale
Common elements of concern:
- Local text entry
- Local text processing (e.g. sorting, comparing)
- Local text display (fonts, ligatures)
- Representation of numbers
- Representation of date and time
- Representation of currency values
- Localised messages
- Localised commands
Principles of Testing
- Each test case must address one requirement (or a part of it)
- Preparation of test cases should begin a lot earlier than their execution
- Pareto principle: 80% of the errors will involve 20% of the code
- Testing should start from small units and end with the complete system
- Testing is never complete
- Effective testing can only be performed by a third party
- Testing should involve black-box and black-box techniques
- Ideally, testing should automated, so that it can be executed after every software modification
Automated testing using the JUnit framework
Maintenance Types and Strategies
Research has shown that maintenance effort is roughly divided into:
- Bug corrections (17%)
- Response to execution environment changes (18%)
- Functionality changes (65%)
Effort on software system can involve:
- Maintenance
- Fixes and new functionality
- Refactoring
- Architectural changes without important functional changes
- Re-engineering
- Re-implementation often without new architectural or functional changes
Configuration Management
Configuration management addresses the following problems:
- Multiple programmers working on the same code
- Notifying group members of code changes
- Software element interdependencies
- Management of software releases
Under configuration management we typically put:
- Specifications
- Data dictionary
- Architectural design
- Module design
- Interfaces
- Test plans and procedures
- Test cases
- Source code
- Documentation
Project Management Pitfalls
Software is Different
- The product has no physical body
- There are no common and commonly accepted development processes
- Large projects are bespoke development efforts
- Software is mistakenly considered malleable
- Small software changes can have large impacts
- Component reuse is not commonly practiced
The most important pitfalls encountered in a software development effort
are (Boehm 1991):
- Personnel shortages
- Non realistic time planning
- Requirements misunderstanding
- Interface usability problems
- Software complexity beyond customer's needs
- Insufficient tracking of changes requirements
- Problems in reused components or external software
- Problems in outsourced elements
- Slow response time
- Project's beyond the current state of the art
Project Management
Project management involves addressing four elements:
- Persons
- Administrative personnel
- Project management personnel
- Programmers
- Customers
- End users
- Product
- Process
- Project
Project Staffing Case Study
NuMega (Sullivan 2001) organises product development around two teams:
- Main team; responsible for
- Project management
- Software development
- QA
- User training
- Usability
- User interface
- Release engineering
- Support team; responsible for
- Product management
- Marketing
- Support
- Beta testing management
To a project manager report the following:
- Development manager
- QA manager
- User manager
- Usability manager
- Release manager
The project manager is responsible for:
- Staffing
- Human resource management
- Project planning and implementation
- Team coordination
- Time plan management
The development manager has a reporting manager for every major functional
requirement.
The development manager is responsible for:
- Architectural and technical elements
- Selecting tools, technologies and standards
- Mentoring other tem members
- Following up on project problems
- Writing code
A manager for each major functional requirement oversees programmers
and is responsible for:
- Agreeing on a common architecture with other managers
- Requirement elicitation and validation
- Designing the specific functionality
- Helping the QA team
- Writing code
Cost Models
- Estimating a project's cost can be very difficult
- Organisational experience plays a major role
- Cost estimates start from code estimates
- Code estimates can be measured in
- Size (e.g. lines of code)
- Function points (e.g. queries, screens, tables, ...)
- Object points
- Constructive estimation techniques (like COCOMO II) exist, but
require organisation and project-specific calibration
10 Productivity Aphorisms
- Correcting an error after delivery can be 100 times more expensive than correcting it during the requirement gathering phase
- A time schedule can be compressed by up to 25%, but no more
- One euro in development effort will amount to two euros in maintenance effort
- Development and maintenance effort are mainly dependent on the size of the program in lines of code
- Staff variability is the major cause behind development productivity variations
- The ratio of software to hardware cost has changed from 15/85 in 1955 to 85/15 in 1985 and continues to expand
- The ratio between design, development, and testing is approximately 60-15-25.
- Software systems and products are three times as expensive as a stand-alone software problem
- Testing will uncover 60% of the errors
- Many software development phenomena and practices follow the 80/20 Pareto rule: 80% of the contribution is due to 20% of the contributors
(IEEE Software, Vol 4, No 5, Sept 1987, pp 84-85).
Agile Development
Manifesto for Agile Software Development
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.
(From the
Agile Manifesto web site (http://agilemanifesto.org/))
eXtreme Programming
Extreme programming is an agile development methodology valuing
- Communication
- Simplicity
- Feedback
- Courage
It involves the following practices:
- Team-based release plans
- Small rapid releases
- Use of architectural metaphors
- Simple designs
- Complete coverage through automated test cases
- Refactoring
- Pair programming
- Collective ownership
- Continuous integration
- A 40-hour week
- On-site customer
- Adherence to coding standards
Bibliography
- Christopher Alexander,
Sara Ishikawa, Murray Silverstein, Max Jacobson, Ingrid Fiksdahl-King, and
Shlomo Angel.
A Pattern Language.
Oxford University Press, 1977.
- Friedrich L. Bauer.
Decrypted Secrets: Methods and Maxims of Cryptology.
Springer Verlag, 1997.
- Kent Beck and Erich
Gamma.
Test infected: Programmers love writing tests.
Java Report, July 1998.
- Kent Beck.
Extreme Programming Explained: Embrace Change.
Addison Wesley Longman, 2000.
- Jon Louis Bentley.
Writing Efficient Programs.
Prentice-Hall, 1982.
- Jon Louis Bentley.
Programming Pearls.
Addison-Wesley, 1986.
- Jon Louis Bentley.
More
Programming Pearls: Confessions of a Coder.
Addison-Wesley, 1988.
- Jon Louis Bentley.
More
Programming Pearls: Confessions of a Coder, chapter Little
Languages, pages 83-100.
Addison-Wesley, 1988.
- Grady Booch, James
Rumbaugh, and Ivar Jacobson.
The
Unified Modeling Language User Guide.
Addison-Wesley, 1999.
- Paul Booth.
An
Introduction to Human-Computer Interaction.
Lawrence Erlbaum Associates, Publishers, New Jersey, USA, 1989.
- F. P. Brooks.
The
Mythical Man Month.
Addison-Wesley, 1975.
- William J. Brown,
Raphael C. Malveau, Hays W. McCormick III, and Thomas J. Mowbray.
AntiPatterns Refactoring Software, Architectures, and Projects in
Crisis.
Wiley, 1998.
- Mark Burgess.
Principles of Network and System Administration.
John Wiley and Sons, 2001.
- Stuart K. Card, Thomas P.
Moran, and Allen Newell.
The
Psychology of Human-Computer Interaction.
Lawrence Erlbaum Associates, Publishers, New Jersey, USA, 1983.
- James O. Coplien and
Douglas C. Schmidt.
Pattern Languages of Program Design.
Addison-Wesley, 1995.
- Michael A. Cusumano
and Richard W. Selby.
Microsoft Secrets.
The Free Press, 1995.
- Tina Darmohray, editor.
Job
Descriptions for System Administrators.
Short Topics in System Administration. USENIX Association, Berkeley, CA, USA,
1997.
- Alan M. Davis.
201
Principles of Software Development.
McGraw-Hill, 1995.
- Tom DeMarco and
Timothy R. Lister.
Peopleware: Productive Projects and Teams.
Dorset House Publishing, 1987.
- Dorothy Elizabeth Robling
Denning.
Cryptography and Data Security.
Addison-Wesley, 1983.
- Institute of Electrical and
Electronics Engineers, Inc., New York, NY, USA.
Information Technology--Software Life Cycle Processes--Software
Development Acquirer-Supplier Agreement, 1995.
EIA/IEEE Interim Standard J-Std-016-1995 (Issued for Trial Use).
- Tom Forester and
Perry Morrison.
Computer Ethics: Cautionary Tales and Ethical Dilemmas in Computing.
MIT Press, 1990.
- Martin Fowler.
Refactoring: Improving the Design of Existing Code.
Addison-Wesley, Boston, MA, 2000.
With contributions by Kent Beck, John Brant, William Opdyke, and Don Roberts.
- Erich Gamma, Richard
Helm, Ralph Johnson, and John Vlissides.
Design
Patterns: Elements of Reusable Object-Oriented Software.
Addison-Wesley, 1995.
- Daniel M. Hoffman and
David M. Weiss, editors.
Software Fundamentals: Collected Papers by David L. Parnas.
Addison-Wesley, 2001.
- Watts S. Humphrey.
Managing the Software Process.
Addison-Wesley, 1989.
- Andrew Hunt and David
Thomas.
The
Pragmatic Programmer: From Journeyman to Master.
Addison-Wesley, Boston, MA, 2000.
- IEEE standard for
software verification and validation plans.
Published by the American National Standards Institute, 1430 Broadway, New
York, New York 10018, February 1987.
ANSI/IEEE Std 1012-1986.
- Institute of Electrical and
Electronics Engineers, Inc., New York, NY, USA.
IEEE Recommended Practice for Software Design Descriptions, 1998.
IEEE Standard 1016-1998.
- Institute of Electrical and
Electronics Engineers, Inc., New York, NY, USA.
Software Reviews, 1997.
IEEE Standard 1028-1997.
- Institute of Electrical and
Electronics Engineers, Inc., New York, NY, USA.
Software Productivity Metrics, 1992.
IEEE Standard 1045-1992.
- Institute of Electrical and
Electronics Engineers, Inc., New York, NY, USA.
Software Quality Metrics Methodology, 1998.
IEEE Standard 1061-1998.
- Institute of Electrical and
Electronics Engineers, Inc., New York, NY, USA.
IEEE Recommended Practice for Software Acquisition (includes IEEE
1062a), 1998.
IEEE Standard 1062-1998.
- Institute of Electrical and
Electronics Engineers, Inc., New York, NY, USA.
Developing Software Life Cycle Processes, 1997.
IEEE Standard 1074-1997.
- Institute of Electrical and
Electronics Engineers, Inc., New York, NY, USA.
Software Maintenance, 1998.
IEEE Standard 1219-1998.
- Institute of Electrical and
Electronics Engineers, Inc., New York, NY, USA.
IEEE Guide for Developing System Requirements Specifications (including
IEEE 1233a), 1998.
IEEE Standard 1233-1998.
- Institute of Electrical and
Electronics Engineers, Inc., New York, NY, USA.
Information Technology - Software Packages - Quality Requirements and
Testing, 1998.
IEEE Standard 1465-1998 (ISO/IEC 12119:1998).
- Institute of Electrical and
Electronics Engineers, Inc., New York, NY, USA.
IEEE Recommended Practice for Architectural Description of Software
Incentive Systems, 2000.
IEEE Standard 1471-2000.
- Institute of Electrical and
Electronics Engineers, Inc., New York, NY, USA.
Adoption of PMI Standard- A Guide to the Project Management Body of
Knowledge, 1998.
IEEE Standard 1490-1998.
- Institute of Electrical and
Electronics Engineers, Inc., New York, NY, USA.
Information Technology - Software Life Cycle Processes - Reuse
Processes, 1999.
IEEE Standard 1517-1999.
- Institute of Electrical and
Electronics Engineers, Inc., New York, NY, USA.
Software Life Cycle Processes-Risk Management, 2001.
IEEE Standard 1540-2001.
- Institute of Electrical and
Electronics Engineers, Inc., New York, NY, USA.
Software Quality Assurance Plans, 1998.
IEEE Standard 730-1998.
- Institute of Electrical and
Electronics Engineers, Inc., New York, NY, USA.
Software Configuration Management Plans, 1998.
IEEE Standard 828-1998.
- Institute of Electrical and
Electronics Engineers, Inc., New York, NY, USA.
Software Test Documentation, 1998.
IEEE Standard 829-1998.
- Institute of Electrical and
Electronics Engineers, Inc., New York, NY, USA.
IEEE Recommended Practice for Software Requirements
Specifications, 1998.
IEEE Standard 830-1998.
- Institute of Electrical and
Electronics Engineers, Inc., New York, NY, USA.
Guide to the Software Engineering Body of
Knowledge, 2001.
Available online http://www.swebok.org.
- Cem Kaner, Jack Falk, and
Hung Quoc Nguyen.
Testing Computer Software.
Wiley, 1999.
- Brian W. Kernighan
and Rob Pike.
The
Practice of Programming.
Addison-Wesley, 1999.
- Susan Lammers.
Programmers at Work.
Microsoft Press, Redmond, Washington, USA, 1989.
- Thomas A.
Limoncelli and Christine Hogan.
The
Practice of System and Network Administration.
Addison-Wesley, 2001.
- Pete McBreen.
Software Craftmanship: The New Imperative.
Addison-Wesley, 2002.
- Steve C McConnell.
Code
Complete : A Practical Handbook of Software Construction.
Microsoft Press, Redmond, WA, 1993.
- Donald A. Norman.
The
Psychology of Everyday Things.
BasicBooks, New York, NY, USA, 1988.
- Donald A. Norman.
The
Invisible Computer.
MIT Press, 1998.
- David L.
Oppenheimer, David A. Wagner, and Michele D. Crabb.
System Security: A Management Perspective.
Short Topics in System Administration. USENIX Association, Berkeley, CA, USA,
1997.
- P. J. Plauger.
Programming on Purpose II: Essays on Software People.
Prentice-Hall, 1993.
- Roger S. Pressman.
Software Engineering: A Practitioner's Approach.
McGraw-Hill, London, fifth edition, 2000.
European Adaptation. Adapted by Darrel Ince.
- J. Christopher Ramming, editor.
USENIX Conference on Domain-Specific Languages, Santa Monica, CA, USA,
October 1997. Usenix Association.
- Jef Raskin.
The
Humane Interface: New Directions for Designing Interactive
Systems.
Addison-Wesley, 2000.
- Eric Steven Raymond.
The Art of Unix Programming.
Addison-Wesley, 2003.
- Aviel D. Rubin, Daniel
Geer, and Marcus J. Ranum.
Web
Security Sourcebook.
John Wiley & Sons, 1997.
- Charles H. Schmauch.
ISO
9000 for Software Developers.
ASQC Quality Press, Milwaukee, Wisconsin, USA, 1995.
- Bruce Schneier.
Applied Cryptography.
Wiley, second edition, 1996.
- Bruce Schneier.
Secrets & Lies: Digital Security in a Networked World.
Wiley Computer Publishing, 2000.
- Ian Sommerville.
Software Engineering.
Addison-Wesley, sixth edition, 2001.
- Diomidis
Spinellis and V. Guruprasad.
Lightweight languages as software engineering tools ( http://www.spinellis.gr/pubs/conf/1997-DSL-Lightweight/html/paper.html).
In Ramming [Ramming, 1997], pages 67-76.
- Diomidis Spinellis
and Konstantinos Raptis.
Component mining: A process and its pattern language ( http://www.spinellis.gr/pubs/jrnl/2000-IST-Components/html/comp.html).
Information and Software Technology, 42(9):609-617, June 2000.
- Diomidis Spinellis.
Explore, excogitate, exploit: Component mining ( http://www.spinellis.gr/pubs/jrnl/1999-Computer-Components/html/comp.html).
IEEE Computer, 32(9):114-116, September 1999.
- Diomidis Spinellis.
Reliable software implementation using domain specific languages ( http://www.spinellis.gr/pubs/conf/1999-ESREL-SoftRel/html/dsl.html).
In G. I. Schuëller and P. Kafka, editors, Proceedings ESREL '99 ---
The Tenth European Conference on Safety and Reliability, pages
627-631, Munich-Garching, Germany, September 1999. ESRA, VDI, TUM, A. A.
Balkema.
- Diomidis Spinellis.
Fear of coding, and how to reduce it ( http://www.spinellis.gr/pubs/jrnl/2001-05-Computer-Fear-of-Coding/html/foc.html).
IEEE Computer, 34(8):98-100, August 2001.
- Diomidis Spinellis.
Notable design patterns for domain specific languages ( http://www.spinellis.gr/pubs/jrnl/2000-JSS-DSLPatterns/html/dslpat.html).
Journal of Systems and Software, 56(1):91-99, February 2001.
- Diomidis Spinellis.
Code Reading: The Open
Source Perspective.
Effective Software Development Series. Addison-Wesley, Boston, MA, 2003.
- John Viega and Gary
McGraw.
Building Secure Software: How to Avoid Security Problems the Right Way.
Addison-Wesley, 2001.
- Damien Watkins, Mark
Hammond, and Brad Abrams.
Programming in the .NET Environment.
Addison-Wesley, Reading, MA, 2002.
- Joseph Weizenbaum.
Computer Power and Human Reason.
Pelican books, 1984.
- Edward Yourdon.
Death
March.
Prentice-Hall, 1997.