1. Introduction to Software Project Management

2. Software Crisis
Describe the impact of rapid increases in computer power and the complexity of the problems that could be tackled.
it refers to the Difficulty of writing correct, understandable, and verifiable computer programs.
The roots of the software crisis are complexity, expectations, and change.
The term was used to describe the impact of rapid increases in computer power and the complexity of the problems that could be tackled. In essence, it refers to the difficulty of writing correct, understandable, and verifiable computer programs. The roots of the software crisis are complexity, expectations, and change.
The term "software crisis" was introduced by some time at the NATO Software Engineering Conference in 1968 at Germany.

3. Software Crisis…..
Software crisis is characterized by inability to develop the desired Software Project because of such problems:
Projects running over-budget.
Projects running over-time.
Software is inefficient.
Software is of low quality.
Software does not meet requirements.
Project is unmanageable/ Code difficult to maintain.
The roots of the software crisis are complexity, expectations, and change. To avoid software crisis, software engineering principles and process are applied strictly.

4. Characteristics of Software
Software is not manufactured in the classical sense, but it is developed or engineered
Software doesn't wear out
Software is flexible
Reusability of component
Software means computer instructions or data. Anything that can be stored electronically is software, in contrast to storage devices and display devices which are called hardware. Also known as computer programs, is the non-tangible component of computers. Computer software contrasts with computer hardware, which is the physical component of computers. Computer hardware and software require each other and neither can be realistically used without the other.

5. Software development Phases

6. What is a project? Some dictionary definitions:
“A specific plan or design”
“A planned undertaking”
“A large undertaking e.g. a public works scheme”
Longmans dictionary
Key points above are planning and size of task
Here are some definitions of ‘project’. No doubt there are other ones: for example
‘Unique process, consisting of a set of coordinated and controlled activities with start and finish dates, undertaken to achieve an objective conforming to specific requirements, including constraints of time, cost and resources’

7. Jobs versus projects
‘Jobs’ – repetition of very well-defined and well understood tasks with very little uncertainty
‘Exploration’ – e.g. finding a cure for cancer: the outcome is very uncertain
‘Projects’ – in the middle!
On the one hand there are repetitive jobs a similar task is carried out repeatedly, for example Kwikfit replacing a tyre on a car or a lecturer giving an introductory talk on project management. The task is well-defined and there is very little uncertainty. In some organizations, software development might tend to be like this – in these environments software process management might be more important than software project management
On the other hand some exploratory activities are very uncertain. Some research projects can be like this – we may not be sure what the outcome will be, but we hope that we will learn some things of importance. It may be very difficult to come up with precise plans, although we would probably have some idea of a general approach.
Projects seem to come somewhere between these two extremes. There are usually well-defined hoped-for outcomes but there are risks and uncertainties about achieving those outcomes.

8. Characteristics of projects
A task is more ‘project-like’ if it is:
Non-routine
Planned
Aiming at a specific target
Work carried out for a customer
Involving several specialisms
Made up of several different phases
Constrained by time and resources
Large and/or complex
Exercise 1.1 in the Software Project Management text is a good way of introducing this material if you have time. I have found this exercise to be a good ‘ice-breaker’. Get each student to list the example activities in an order which matches the degree to which they merit the description of ‘project’. You can create a grid on a whiteboard with the projects on the vertical axis and the positions 1st, 2nd, 3rd etc on the horizontal axis. You then go through asking how many put ‘producing a newspaper’ first, second, etc. (Avoid making jokes about this being like the Eurovision song contest). This is time-consuming but it does mean that every student participates in building up a general picture of people’s perceptions, and you can discuss disagreements in perceptions as you go along.

9. Are software projects really different from other projects?
Not really! …but…
Invisibility
Complexity
Conformity
Flexibility
make software more problematic to build than other engineered artefacts.

10. What is management? This involves the following activities:
Planning – deciding what is to be done
Organizing – making arrangements
Staffing – selecting the right people for the job
Directing – giving instructions
continued…

11. What is management? (continued)
Monitoring – checking on progress
Controlling – taking action to remedy hold-ups
Innovating – coming up with solutions when problems emerge
Representing – liaising with clients, users, developers and other stakeholders
Exercise 1.6 (a day in the life of a project manager) is of relevance here.

12. Setting objectives
Answering the question ‘What do we have to do to have a success?’
Need for a project authority
Sets the project scope
Allocates/approves costs
Could be one person - or a group
Project Board
Project Management Board
Steering committee
Different people who are involved in a project (Stakeholders) will have different interests in the project and are likely to see different outcomes as being important.
For example, end-users would want a system that is ‘user-friendly’, that is, easy to learn and to use, and a system that helps rather than hinders them from doing their jobs. Their managers may be more interested in whether the new system would allow them to reduce staffing levels.
It is important therefore that a set of clearly defined objectives are identified and published for the project. Some individual or group needs to be pinpointed who acts as the main client for the project.
See Exercise 1.7 in the text.

13. Objectives The project will be regarded as a success if………………………………..
Informally, the objective of a project can be defined by completing the statement:
The project will be regarded as a success if………………………………..
Rather like post-conditions for the project
Focus on what will be put in place, rather than how activities will be carried out
The focus here needs to be on what the situation will be when the project is completed. In what ways will the world be different? The objectives should avoid describing activities:
e.g. ‘a new payroll application will be operational by 4th April’ not ‘design and code a new payroll application’

14. Objectives should be SMART
S – specific, that is, concrete and well-defined M – measurable, that is, satisfaction of the objective can be objectively judged A – achievable, that is, it is within the power of the individual or group concerned to meet the target R – relevant, the objective must relevant to the true purpose of the project T – time constrained: there is defined point in time by which the objective should be achieved
I have seen some places where the R is said to stand for ‘resource-constrained’, that is that there is a target cost associated with the achievement of the objective.

15. Goals/sub-objectives
These are steps along the way to achieving the objective. Informally, these can be defined by completing the sentence…
Objective X will be achieved
IF the following goals are all achieved
A……………
B……………
C…………… etc

16. Goals/sub-objectives continued
Often a goal can be allocated to an individual.
Individual may have the capability of achieving goal, but not the objective on their own e.g.
Objective – user satisfaction with software product
Analyst goal – accurate requirements
Developer goal – software that is reliable

17. Measures of effectiveness
How do we know that the goal or objective has been achieved?
By a practical test, that can be objectively assessed.
e.g. for user satisfaction with software product:
Repeat business – they buy further products from us
Number of complaints – if low etc etc

18. What is software management?
Software Engineering (Software Management) is the study and application of engineering to the design, development, and maintenance of software.
Typical formal definitions of software engineering are:
"the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software"
"an engineering discipline that is concerned with all aspects of software production"
"the establishment and use of sound engineering principles in order to economically obtain software that is reliable and works efficiently on real machines"
The term has been used less formally:
as the informal contemporary term for the broad range of activities that were formerly called computer programming and systems analysis;
as the broad term for all aspects of the practice of computer programming, as opposed to the theory of computer programming, which is called computer science;
as the term embodying the advocacy of a specific approach to computer programming, one that urges that it be treated as an engineering discipline rather than an art or a craft, and advocates the codification of recommended practices
Link:

19. Common Problems with Software Projects
People-related problems
Low motivation
Problem employees
Unproductive work environment
Inefficient project management style
Lack of stakeholder interest
Ineffective project sponsorship by management
Process-related problems
Unrealistic schedule
Insufficient identification
Unsuitable life cycle model selection
Abandoning quality under pressure of deadlines
Unstructured and hurried software development

20. Common Problems with Software Projects
Product-related problems
Product scope changed toward the end of the project life cycle
Research-oriented software development
Ill-defined scope
Fuzzy users
Technology-related problems
Overestimated savings from reusable components and new tools and methods
Switching tools in mid-way
Integrating different software products in cross-platform implementation

21. Project Planning

22. Planning
Project Planning is an aspect of Project Management that focuses a lot on Project Integration. The project plan reflects the current status of all project activities and is used to monitor and control the project.
The Project Planning tasks ensure that various elements of the Project are coordinated and therefore guide the project execution.
Project Planning helps in - Facilitating communication - Monitoring/measuring the project progress, and - Provides overall documentation of assumptions/planning decisions
The Project Planning Phases can be broadly classified as follows: - Development of the Project Plan - Execution of the Project Plan - Change Control and Corrective Actions
Project Planning is an ongoing effort throughout the Project Lifecycle.

23. Why is it important? “If you fail to plan, you plan to fail.”
Project planning is crucial to the success of the Project. Careful planning right from the beginning of the project can help to avoid costly mistakes. It provides an assurance that the project execution will accomplish its goals on schedule and within budget.

24. Major issues of Software Project Management
Requirements Managements
Resource management
Risk Management
Critical Path Management
Progress Management
Quality Management
Matrix Management

25. Requirements Managements
Goal: features, functions
Failure Points: Incomplete and/or ambiguious requirements
Impact

26. Formal Methods Every Software engineering methodology is based
on a recommended development process
proceeding through several phases:
Analysis,Specification,Design,Coding,Unit Testing,
Integration and System Testing, Maintenance
n Formal methods can:
Be a foundation for describing complex systems
Be a foundation for reasoning about systems
Provide support for program development
Complimentary approach to methodology!

27. Testing: Static vs Dynamic Analysis
Static analysis of code Does not require
execution of code
Lexical analysis of the program syntax and investigates and checks the structure and usage of individual statements; often automated
Dynamic Analysis of code Involves running the system (testing)
Program run formally under controlled conditions with specific results expected
Path and Branch Testing

28. What are Formal Methods?
Techniques and tools based on mathematics and formal logic
Can assume various forms and levels of rigor

29. Why Consider Formal Methods?
Systems are increasingly dependent on software components
Complexity of systems with embedded software has increased rapidly
Maintaining reliability in software-intensive systems is very difficult

30. Formal Methods Concepts
Formal Specification Methods
Formal Specifications
Formal Proofs
Model Checking
Abstraction

31. Formal Specifications
Translation of a non-mathematical description (diagrams, tables, English text) into a formal specification language
Concise description of high-level behavior and properties of a system
Well-defined language semantics support formal deduction about specification

32. Types of Specifications I
Informal
Free form, natural language
Ambiguity and lack of organization can lead to incompleteness, inconsistency, and misunderstandings
Formatted
Standardized Syntax
Basic consistency and completeness checks
Imprecise semantics implies other sources of error may still be present

33. Formal Specifications…
Syntax and semantics rigorously defined
Precise form, perhaps mathematical
Eliminate imprecision and ambiguity
Provide basis for mathematically verifying equivalence between specification and implementation
May be hard to read without training

34. Formal Specifications
Goal: Describe external behavior without describing or constraining implementation
Formal Method has 2 parts:
Logical Theory: Means by which one reasons about specifications, properties and programs
First order predicate calculus (quantification over variables)
Second order predicate calculus (quantification over relations)
Temporal logic
Structuring Theory: Defines elements being reasoned about

35. Types of Formal Specifications
Property Oriented: State desired properties in a purely declarative way
Algebraic: Data type viewed as an algebra, axioms state properties of data type’s operations
Axiomatic: Uses first order predicate logic, pre and post conditions Operational Specification: Describe desired behavior by providing model of system
Model Oriented: Provide direct way of describing system behavior (sets, sequences, tuples, maps) :
Abstract Model (in terms previously defined mathematical objects eg. sets, sequences, functions, mappings)
State machines

36. Property Oriented: Algebraic Specifications
Uses
Input-Output Assertions
Sets of operations
Axioms specifying behaviour of operations
Two parts to a specification
syntax
axioms

37. Model Oriented: Abstract Model Specifications
Build an abstract model of required software behaviour using mathematically defined types (sets, relations)
Define operations by showing effects of that operation on the model
Specification includes:
Model Type
Invariant properties of model
For each operation
Name, parameters, return values

38. Formal Proofs
Complete and convincing argument for validity of some property of the system description
Constructed as a series of steps, each of which is justified from a small set of rules
Eliminates ambiguity and subjectivity inherent when drawing informal conclusions
May be manual but usually constructed with automated assistance

39. Model Checking Operational rather than analytic
State machine model of a system is expressed in a suitable language
Model checker determines if the given finite state machine model satisfies requirements expressed as formulas in a given logic
Basic method is to explore all reachable paths in a computational tree derived from the state machine model

40. Abstraction Simplify and ignore irrelevant details
Focus on and generalize important central properties and characteristics
Avoid premature commitment to design and implementation choices

41. Benefits of Formal Specifications
Higher level of rigor enables a better understanding of the problem
Defects are uncovered that would likely go unnoticed with traditional specification methods
Identify defects earlier in life cycle
Can guarantee the absence of certain defects
Formal specification language semantics allow checks for self-consistency of a problem specification
Formal specifications enable formal proofs which can establish fundamental system properties and invariants
Repeatable analysis means reasoning and conclusions can be checked by colleagues
Abstract formal view helps separate specification from design

42. Conclusion FM are no panacea
FM can detect defects earlier in life cycle
FM can be applied at various levels of resource investment
FM can be integrated within existing project process models
FM can improve quality assurance when applied judiciously to appropriate projects

43. Logic and Propositional Calculus

44. Logic
A propositional calculus or logic (also called sentential calculus or sentential logic) is a formal system in which formulas of a formal language may be interpreted as representing propositions.
The term proposition refers to either
the "content" or "meaning" of a meaningful declarative sentence or
the pattern of symbols, marks.
You will be familiar with the following notions.
IF p THEN q
TRUE, FALSE
For all, There exists

45. Logic consists of
A language which tells us how to build up sentences in the language (i.e., syntax), and and what the sentences mean (i.e., semantics)
An inference procedure which tells us which sentences are valid inferences from other sentences

46. Propositional logic
The symbols of propositional calculus are the propositional symbols:
P, Q, R, S, …
the truth symbols:
true, false
and connectives:
, , , , 

47. Propositional Calculus Sentences
Every propositional symbol and truth symbol is a sentence.
Examples: true, P, Q, R.
The negation of a sentence is a sentence.
Examples: P,  false.
The conjunction, or and, of two sentences is a sentence.
Example: P  P

48. Propositional calculus semantics
An interpretation of a set of propositions is the assignment of a truth value, either T or F to each propositional symbol.
The symbol true is always assigned T, and the symbol false is assigned F.
The truth assignment of negation, P, where P is any propositional symbol, if F is the assignment to P is T, and if T is the assignment to P is F.
The truth assignment of conjunction, , is T only when both conjuncts have truth value T; otherwise it is F.

49. Propositional calculus semantics (cont’d)
The truth assignment of disjunction, , is F only when both disjuncts have truth value F; otherwise it is T.
The truth assignment of implication, , is F only when the premise or symbol before the implication is T and the truth value of the consequent or symbol after the implication F; otherwise it is T.
The truth assignment of equivalence, , is T only when both expressions have the same truth assignment for all possible interpretations; otherwise it is F.

50. For propositional expressions P, Q, R

51. Fig. 2.1: Truth table for the operator 

52. Predicate calculus symbols
The set of letters (both uppercase and lowercase): A … Z, a … Z.
The set of digits: 0 … 9
The underscore: _
Needs to start with a letter.

53. Symbols and terms
1. Truth symbols true and false (these are reserved symbols)
2. Constant symbols are symbol expressions having the first character lowercase.
E.g., today, fisher
3. Variable symbols are symbol expressions beginning with an uppercase character.
E.g., X, Y, Z, Building
4. Function symbols are symbol expressions having the first character lowercase. Arity: number of elements in the domain
E.g., mother-of (bill); maximum-of (7,8)

54. Predicates and atomic sentences
Predicate symbols are symbols beginning with a lowercase letter. Predicates are special functions with true/false as the range. Arity: number of arguments
An atomic sentence is a predicate constant of arity n, followed by n terms, t1 ,t2 ,…, tn, enclosed in parentheses and separated by commas.
The truth values, true and false, are also atomic sentences.

55. Predicate calculus sentences
Every atomic sentence is a sentence.
1. If s is a sentence, then so is its negation, s.
If s1 and s2 are sentences, then so is their
2. Conjunction, s1  s2 .
3. Disjunction, s1  s2 .
4. Implication, s1  s2 .
5. Equivalence, s1  s2 .

56. Predicate calculus sentences (cont’d)
If X is a variable and s is a sentence, then so are
6. X s.
7. X s.

57. Can also use functions A person’s mother is that person’s parent.
X person (X) parent(mother-of(X),X)
There are people who think this class is cool.
X person (X)  T (X)
Some computers have mouses connected on the USB.
 X computer (X)  USB_conn (X, mouse_of(X))

58. First-order predicate calculus
First-order predicate calculus allows quantified variables to refer to objects in the domain of discourse and not to predicates or functions.
John likes to eat everything.
X food(X)  likes (john,X)
John likes at least one dish Jane likes.
F food(F)  likes (jane, F)  likes (john, F)
John “does” everything Jane does.
P P(Jane)  P(john) This is not first-order.

59. Order of quantifiers matters
Everybody likes some food.
There is a food that everyone likes.
Whenever someone likes at least one spicy dish, they’re happy.

60. Order of quantifiers matters
Everybody likes some food.
X F food(F)  likes (X,F)
There is a food that everyone likes.
F X food(F)  likes (X,F)
Whenever someone eats a spicy dish, they’re happy.
X F food(F)  spicy(F)  eats (X,F)  happy(X)

61. Examples John’s meals are spicy.
Every city has a dogcatcher who has been bitten by every dog in town.
For every set x, there is a set y, such that the cardinality of y is greater than the cardinality of x.

62. Examples John’s meals are spicy. X meal-of(John,X)  spicy(X)
Every city has a dogcatcher who has been bitten by every dog in town.
T C D city(C)  ( dogcatcher(C,T) 
(dog(D)  lives-in (D, T)  bit (D, C)) )

63. Second Order Predicate calculus
second-order logic is an extension of first-order logic, Second-order logic is in turn extended by higher-order logic and type theory.
First-order logic uses only variables that range over individuals (elements of the domain of discourse); second-order logic has these variables as well as additional variables that range over sets of individuals.
For example, the second-order sentence P x (x є P V x € P)says that for every set P of individuals and every individual x, either x is in P or it is not.
Both first-order and second-order logic use the idea of a domain of discourse (often called simply the "domain" or the "universe").
The domain is a set of individual elements which can be quantified over.