CMPE 412 Software Engineering

1. CMPE 412Software Engineering Asst.Prof.Dr.Duygu Çelik Ertuğrul Room: CMPE 206 Email: duygu.celik@emu.edu.tr

2. Project Management Concepts What are the key concepts that lead to effective SPM? How can we measure progress in software projects? How can estimate cost and resource requirements for a software Project, so that we make an effective Project plan? How can we ensure the quality of a software Project? Pressman discusses those topics in Chapters 3 to 9 (Source: Pressman, R. Software Engineering: A Practitioner’s Approach. McGraw-Hill, 2005)

3. Project management • “Project management involves the planning, monitoring, and control of the people, process and events that occur as software grows from preliminary concept to operational implementation.” – Pressman, 2000 • For most projects, important goals are: • Deliver the software to the customer at the agreed time. • Keep overall costs within budget. • Deliver software that meets the customer’s expectations. • Maintain a happy and well-functioning development team.

4. divide-and-solve Chapter 3Project Management Concepts PRODUCT PROJECT Effective SPM focuses on 3 P’s: The People The Problem The Process Problems Process Bla..bla..bbla. People Finish Start (Source: Pressman, R. Software Engineering: A Practitioner’s Approach. McGraw-Hill, 2005)

5. People Problem Project Product Process

6. Effective SPM focuses on 3 P’s: • People must be organized to perform software work effectively. • A process must be selected that is appropriate for the people and the product. • The project must be planned by estimating effort and calendar time to accomplish work tasks.

7. PEOPLE • Software engineering work is heavily dependent on HUMAN FACTOR/WORK. • In 1988, the engineering vice presidents of three major technology companies were asked about the most important contributor to a successful software project.

8. Their answers were as follows: • VP1: It’s not the tools we use, but it’s the people. • VP2: It is having smart people. Very little else matters in my opinion. The most important thing you do for a Project is selecting the staff. • VP3: The only rule I have in management is to ensure I have really good people . Then, I provide an environment in which good people can work. • So, Who are the ‘Players’ who participate in the software development process?

9. Participants • 1. Senior Managers: define the business issues. Coordinate the interface between the business and the software professionals. • 2. Project Managers: Plan, motivate, organize and control people who do technical aspects of work – the practitioners. • Practitioners: Convey necessary technical skills to engineer product • A software engineer manages day-to-day activities, planning, monitoring, and controlling technical tasks. • 4. Customers & Stakeholders: specify the requirements and scope for software project. • 5. End Users: use the software once it is delivered.

10. The People: Team Leaders • Project Management: is a people-intensive activity. • So, practitioners often fail to be good team leaders; they just don’t have the right skills. • Weinberg’s MOI model->abilities to look for a team leader • Motivation • Ability to encourage technical people to work to the best of their abilities (push or pull) • Organization • Ability to adapt existing processes, or inventnew ones, to enable the concept to be turned into a product • Ideas/Innovation • Ability to encourage people to create, and to feel creative, within the bounds of the particular product

11. Problem Solving Experience • Team leaders should use a problem-solving management style (acc. to the Weinberg’s model ) • Concentrate on understanding the problem to be solved • Manage the flow of ideas • Team leader must let everyone know (by words and. by actions)that quality is important – lead by example!

12. Another view of what makes a good team leader: (acc. to the Edgemon’s model ) • A good Project Manager (PM) is responsible for: • Problem solving • Decide which technical and organizational issues are most important • Create a systematic solution to the problem – or motivate others to do so • Apply lessons from past projects to new ones • Remain flexible enough to change direction if initial proposed solutiondoesn’t work • Managerial Identity • Should be ConfidentConfidence to take control of project when necessary, but also to let good technical people use their initiative (encourage them to apply their initiative) • Achievement • Reward initiative and accomplishmentof team members • Demonstrate that controlled risk-taking will not be punished • Influence and Team building • Be able to “read” people – understand both verbal and non-verbal signals from team members, and react to their needs

13. The People: The Software Team • There are many team structures for SW development. • We shall assume that there are n people in the team. • OPTION 1: • n individuals are assigned to m different functional tasks, n<m (5 people, 10 tasks) • little combined work is done by them. • Coordination of individuals is the responsibility of the SW manager. • The manager may be dealing with other projects at the same time (Many-project responsibility). • OPTION 2: • n individuals are assigned to m different functional tasks (i.e. 10 people, 5 tasks). • One person in the team may be appointedas a Team Leader • But, m<n, so relaxed/informal TEAMs are established. • Coordination among the TEAMs is the responsibilityof the SW Manager. • OPTION 3 (Team-Oriented): • n individuals are assigned to t teams.(10 people, 5 teams). • Each team is assigned one or more functional tasks • Each team has a specific structure. • Coordination is controlled by both the team leader and a SW Manager.

14. The People: The Software Team • Most people think that OPTION 3, that is, a formal team organization is most PRODUCTIVE! • The BEST team structure depends on: • The management style of the organization • The # of people who will participate in Teams and their skill levels, • The difficulty of the overallproject.

16. Mantei(81): team structures • SW teams can be organized into number of different team structures • appropriate team structure depends on type of problem task • 3 generic team organizations

17. The People: The Software Team (continued) Mantei suggests three types of organizational paradigms for software development teams: • Democratic Decentralized (DD) • No permanent leader. • task coordinators appointed for short time and then replaced • decisions made by group consensus (taken joint decisions) • horizontal communication(no hierarchy) • Controlled Decentralized (CD) • There is a defined leader who coordinates tasks • There are secondary leaders whoresponsible for subtasks • Group problem solving- Implementation of solution is partitioned among subgroups by the Team Leader (group problem solving) • Horizontal communication among subgroups • Vertical communication along control hierarchy

18. The People: The Software Team (continued) 3) Controlled Centralized (CC) • There is a defined leader. • The leader manages top level problem solving and internal team coordination. • Vertical communication between leader and team members. Table 3.1 P.63 in text - summarizes impact of project characteristics on team structure (Mantei 81)

19. CC/CD is best subgrouping CC/CD has fewer defect than DD D model has more sociability (girişken)! DD is best for low Modularity bcz higher communication in team DD is best for Long Team Life: bcz, high team morale, live together,job satisfaction

20. Project structures • Since centralized model completes tasks faster - better at handling simple problems. • Decentralized model - generates more and better solutions so better at more difficult problems. • Controlled Decentralized (CD) team or CC (Controlled Centralized) team • DD structure is the best for Difficult Problems. • Very large projects are best addressed by CC and CD teams. Bcz, subgrouping helps to reduce the amount of communication that must be conducted.

21. Project structures • DD teams bring about higher moral and job satisfaction. So, DD is suitable for a long time group work. • Bcz, in DD teams, a high amount of communication is needed. So the DD team structure is best for problems with relatively low modularity (low size of project). • When high modularity (high size of project) is possible (and people can do their own parts alone), the CC and CD structure should be preferred. • CC and CD type teams have been found to Produce Fewer Defects than DD type teams. • Decentralized teams generally require more time to complete a project. • Also, they are better when high socaibility (friendliness)is required.

22. The Montei also described the seven important project factors when organizingateam: • The difficulty of the problem to be solved. • The size of the resultant program(s) in source lines of code / LOC. • The time that the team will stay together. • The degree to which the problem can be modularized. • The requiredquality and reliability of the system to be built. • The inflexibility of the delivery date. • The degree of sociability (communication) requiredfor the project.

23. Constantine’s Organizational Paradigms for SE Teams 1.Closed Paradigm (Similar to CC) 2.Random Paradigm 3.Open Paradigm 4.Synchronous Paradigm

25. 1.Closed Paradigm: (Similar to CC) • Tradional/team work based always on standard tasks • Works well especially if teams are working on projects that are similar to the ones completed in the past(previous completed projects). • There is a strict hierarchy of authority. • Can not be innovative(bringing in new ideas, processes, new innovations.)

26. 2.Random Paradigm • The team is inaccurately (loosely) structured, depends on individual initiativeof the team members. • These type of teams will be successful when innovation or a technological advance is required (for example, developing software for a new machine). • When routine projects (similar projects)are considered or performed,this organization may cause problems.

27. 3.Open Paradigm: • A combination of the Open= Closed + Random paradigms. • There is strict hierarchy of authority like in the Closed paradigm, can also be innovative like the Random paradigm. • Work is performed collaboratively, and there is a lot of communication, decision making is based on the consensus of the team. • Suitable for solving complex problems. • Not as efficient asother paradigms.

28. 4.Synchronous Paradigm: • Suitable for problemsthat can be divided easily into sub problems. • Team membersare organized to work on sub problems with little communication.

29. Systems analysis Software development Plans, Coordinates, reviews all activities Helps the senior Eng. (can replace him/her if needed) Software Librarian Senior Eng. (Chief Programmer) Technical Staff 2-7 People Backup Eng. Figure. Earliest software team organization model. Chief programmer team (Harlas Hills, Baker) similar to CC.

30. 1.The chief programmer may be served: • by one or more specialists (i.e. Database designer, telecom, expert,...), • by support staff (i.e. Secretaries, technical writers) • a software librarian. 2.The software librarian serves many teams. • His/she maintains and controls source listings, data, backups and documentation. • Also collects software productivity parameters of technical staff and assists teams in research, evaluation and document preparation. *Good teams should have same «Team Spirit».

31. Coordination & Communication in SW Projects • There are many reasons that SW projects run into problems: • The problem to solve is too large, complex or confusing, so the team members cannot be coordinated property. • There is a lot of uncertainty in the early stages of the problem definition and this results in many changes in requirements. • Modern SW Eng. requires interoperability: a new SW must communicate with existing modules properly and satisfy the predefined constraints. • So, a SE team must found effective methods for coordinating the team members. • Formal and informal communication mechanisms within teams, and between teams must be established properly. • For Formal Communication: write reports, organize meetings. • For Informal Communication: mostly something personal, team members share ideas, ask for help of others, interact with one another daily.

32. Kraul and Streeter’s Collection of Project Coordination Techniques A)Formal, impersonal approaches: • Source code, SE documents (e.g., systems requirements), technical memorandums, project milestones, projects schedules, project control tools, requests for change, error tracking reports. B) Formal, interpersonal procedures: Quality assurance activities applied to SE products. • Status review meetings, designmeetings, code reviews.

33. C) Informal,Interpersonal Procedures: • group meetings to inform all team members, • group meetings for problem solving. D) Electronic Communication: • E-mail, bulletin/discussion boards, shared websites, video conferencing. E) Interpersonal Network: • Informal discussions with those outside the company, who (e.g.,software consultants, e.g. ASELSAN) have experience and insight that can help team members working on the Project

34. People Problem Project Product Process

35. II.The Problem • A SW Project manager has a difficult task at the beginning of a new project. • There’s no much information about project, • but some quantitative estimates (like how much time will be needed, how many programmers are needed) and • a project organization plan is required. • A detailed analysis of software requirements will provide this information eventually. • But this study takes a lot of time (weeks or months). • The requirements may be changing during the projects, which make things worse. • So, what to do at the beginning of the project?

36. Define Software Scope • First activity is to determine the software scope by the project manager. • This can be done by answering the following questions: • How does the SW to be developed fit into a larger system? (context)What constraints are compulsory? • What customer-visible objects are to be produced?What data objects are required for input?(Information Objectives) • What function will the software perform to transform input data to outputs? (Any special performance characteristics?)(Function and Performance)

37. Project scope must be understandable, and unmistakable for the project manager. • A statement of project scope must be bounded, so quantitative data (e.g.,no.of simultaneous users, max. allowable response time) are stated explicitly. • Constraints and/or limitations are noted. (e.g.,if the product is thought to be cheap,memory size may be restricted, etc.) • Algorithms to be used are well understood and properly described.