1. Software Engineering
Project Management

2. Objectives
To summarize the software engineering life cycle and a simple object oriented process
To introduce the role of project management
To discuss the management of technical people

3. Analysis Summary Process Model Output
1. Elicit customer requirements and identify use-cases
Use-Case Diagrams
2. Extract candidate classes, Identify attributes and methods, Define a class hierarchy
Class Responsibility Collaborator (CRC) Cards
3. Build an object-relationship model (structural)
Conceptual Class Diagram
4. Build an object-behaviour model (dynamic)
Interaction and State Diagrams
analysis
design
code
test

4. Design Summary Process Model Output
1. Subsystem Design: partition the system into components
A Package Diagram
2. Class and Object Design: define class hierarchies
Specification Class Diagram
3. Message Design: convert the object-relationship model into a set of class messages
Message Descriptions
4. Responsibility Design: specify the internal structure of classes
Specification Class Diagram with full attribute and method syntax
C++ Class Headers
analysis
design
code
test

5. Testing Summary Process Technique
1. Class Testing: test methods and state behaviour of classes
Random, Partition and White-Box Tests
2. Integration Testing: test the interaction of sets of classes
Random and Behavioural Testing
3. Validation Testing: test whether customer requirements are satisfied
Use-case based black box and Acceptance tests
4. System Testing: test the behaviour of the system as part of a larger environment
Recovery, security, stress and performance tests
analysis
design
code
test

6. Project Management An umbrella activity.
Planning, organizing, controlling and monitoring software development.
Elements of Project Management (the 4 P’s):
Product (the software to be built)
Process (the set of framework activities and software engineering tasks to get the job done)
People (the most important element of a successful project)
Project (all work required to make the product a reality)
Tightly interrelated (each depends on the other)

7. Project Management Concerns
product quality? ?
risk assessment?
measurement?
cost estimation?
project scheduling?
customer communication?
staffing?
other resources?
project monitoring?

8. Product Management
Need sufficient initial information to plan the project.
Part of System Engineering and early Requirements Analysis.
Establish Scope:
a narrative that bounds the problem.
Context (How does the software to be built fit into a larger system, product or business context and what constraints are imposed as a result of the context?)
Information Objectives (What customer visible data objects are input and output?)
Function and performance (What function does the software perform in transforming inputs to outputs. Special performance characteristics?)
decompose problem:
establishes an initial functional partitioning

9. Process Management
The project manager must decide which process model (linear, prototyping, RAD, spiral, component-based) is most appropriate for:
the customers and practitioners
the characteristics of the product
the project environment in which the software team works
Melding the Product and Process:
the product functions are listed (vertical) against the process tasks (horizontal).
Each cell holds resource requirements, estimated start and end dates and work products.

10. Melding Problem and Process.
Melding Problem and Process
Process
Activities
COMMON PROCESS
communication
planning
analysis
engineering
FRAMEWORK ACTIVITIES
customer
risk
Software Engineering Tasks
Product Functions
Text input
Editing and formating
Automatic copy edit
Page layout capability
Automatic indexing and TOC
File management
Document production

11. People Management
Management in major technology companies rightly believes that people are the key to success:
CIO1: “I guess if you had to pick one thing out that is most important in our environment, I’d say it’s not the tools that we use, it’s the people”.
CIO2: “The most important ingredient that was successful on this project was having smart people...very little else matters in my opinion”.
CIO3: “The only rule I have in management is to ensure that I have good people – real good people – and that I grow good people – and that I provide an environment in which good people can produce”.
But their actions often contradict this belief.
Good management is more than just free coffee.

12. The Players
Senior Managers: define the business issues that have significant influence on the project
Project (Technical) Managers: responsible for planning, motivating, organizing and controlling the practitioners who do software work.
Practitioners: deliver the technical skills that are necessary to engineer a product or application.
Customers: specify the requirements of the software being engineered.
End-Users: interact with the system once it is released for production use.

13. Team Structures
Democratic Decentralized (DD): No permanent leader, appointed for short duration. Decisions on problems and approach are made by group consensus. Little control and horizontal communication.
Controlled Decentralized (CD): A defined leader who co-ordinates specific tasks. Problem solving is a group activity but implementation of solutions is partitioned among subgroups. Control is vertical and communication is horizontal
Controlled Centralized (CC): Top-level problem solving and internal team coordination are managed by a team leader. Control is hierarchical and communication is vertical. Early example – the “Chief Programmer” structure.
What about Democratic Centralized (DC)?

14. Issues in Choosing Team Structure
The following factors must be considered when selecting a software project team structure:
the difficulty of the problem to be solved
the size of the resultant program(s) in lines of code or function points
the time that the team will stay together (team lifetime)
the degree to which the problem can be modularized
the required quality and reliability of the system to be built
the rigidity of the delivery date
the degree of sociability (communication) required for the project

15. Exercise: Which Team Structure?
What team structure would you choose if you had been appointed as a project manager for:
A small software products company. Task: build a breakthrough product that combines virtual reality hardware with state of the art software. Because competition for the home entertainment market is intense, there is significant pressure to get the job done.
A company that services the genetic engineering world. Task: manage the development of a new software product that will accelerate the pace of gene typing. The work is R&D oriented, but must produce a product within the year.
An information systems organization. Task: build an application that is quite similar to others your team has built, although this one is larger and more complex. Requirements have been thoroughly documented by the customer.

16. Team Structure Solutions
There are no absolutes in dealing with people.
Centralized: Fast. Works for simple well-defined problems. Scales well, since performance of teams is inversely proportional to amount of communication.
Decentralized: More and better solutions. Works for difficult problems. Not good for modular problems.
Democratic: leads to higher morale and job satisfaction
Answers:
Controlled Decentralized
Democratic Decentralized
Controlled Centralized

17. Jelling Jell: Team Toxicity (factors that work against jelling):
In business any group assigned to work together is termed a “team” but they often don’t have a common definition of success or a team spirit
An effective tightly knit group displays Jell or “Esprit de Corps”. “Once a team begins to jell, the probability of success goes way up. The team can become unstoppable, a juggernaut for success”.
Team Toxicity (factors that work against jelling):
A frenzied work atmosphere (which wastes energy and lacks focus)
High frustration caused by personal, business, or technological factors that cause friction among team members.
Fragmented or poorly coordinated procedures.
Unclear definition of roles resulting in a lack of accountability.
Morale damaged by continuous and repeated failure.

18. Coordination and Communication
Project coordination techniques can be categorized as:
Formal, impersonal approaches (software engineering documents and deliverables, technical memos, project milestones, repository data)
Formal, interpersonal procedures (status review meetings, design and code inspections)
Informal, interpersonal procedures (group meetings and problem solving)
Electronic communication ( , electronic bulletin boards)
Interpersonal networking (informal “tea break” discussions)

19. Value and Use of Coordination
Line of Equal Use and Value
Formal Impersonal
Formal Interpersonal
Discussion with Peers
Informal Interpersonal
Design Review
Documents
Electronic Comm.
Requirements Review
Interpersonal Network
Milestones
Collocation
Group Meetings
Code Inspections
Value
Project Bulletins
Source Code
Use
Data from a rating study of 65 projects

20. Project Management
The high-level activities needed to co-ordinate different aspects of the project. The driving mechanism.
A difficult juggling act:
size
delivery deadline
budgets and costs
application domain
technology to be implemented
system constraints
user requirements
available resources

21. Why Projects Fail An unrealistic deadline is established
Changing customer requirements or technology
An honest underestimate of effort
Predictable and/or unpredictable risks
Technical difficulties
Miscommunication among project staff
The project team lacks people with appropriate skills
Failure in project management

22. W5HH Principles
There are certain questions which need to be asked in creating an initial project management plan:
Why is the system being developed?(i.e. Does the business purpose justify the expenditure of people, time and money?)
What will be done? By when? (Helps with a project schedule and milestones)
Who is responsible for a function? (roles and responsibilities for team members)
Where are they organizationally located? (customers and users also have responsibilities)
How will the job be done technically and managerially? (a management and technical strategy is needed)
How much of each resource (e.g., people, software, tools, database) will be needed? (need to estimate project metrics)

23. Critical Practices
U.S. Department of Defense developed a list of practices considered critical by successful software organizations:
Formal risk analysis. What are the top ten risks for this project? For each, what is the chance of occurrence and impact?
Empirical cost and schedule estimation. Current estimated size of application software and delivery date.
Metrics-based project management. Need to have in place a metrics program as an early warning system.
Earned value tracking. Each task given a budgeted cost (in person days). Keep track of progress towards the total.
Defect tracking against quality targets. Are the number of open and closed defects tracked from project inception?
People aware project management. Staff turnover.