Software Engineering

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 analysis design code test

4. Design Summary analysis design code test

5. Testing Summary 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 Process Activities COMMON PROCESS communication engineering analysis planning risk FRAMEWORK ACTIVITIES customer 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: • 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 (e-mail, 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 E-mail Group Meetings Code Inspections Value Project Bulletins Source Code Data from a rating study of 65 projects Use

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.