CEN 4021 Software Engineering II

1. CEN 4021 Software Engineering II • Software Project Planning (POMA) • A Review Instructor: Masoud Sadjadi http://www.cs.fiu.edu/~sadjadi/ sadjadi@cs.fiu.edu

2. Acknowledgements • Dr. Onyeka Ezenwoye • Dr. Peter Clarke

3. Agenda • Organizing (POMA) • A review

4. Organization • Seeks to construct a software development, support, and service organization based on the project plan. • Activities include: • Acquiring various skilled individuals needed for the project. • Obtaining the tools to support the process and methodologies. • Creating a set of well-defined metrics to track and gauge the project.

5. Human Resources • Possible software organizational structures • Software development organization • Software support organization • Preparations to acquire human resources • Recruiting, hiring • Projects require • large number of people with range of skills. • Multiple teams with specialized skills (e.g., testing, installation). • Personnel hiring may be done in parallel with preparing organizational structure. • Organizing groups require understanding of project plan.

6. Fig. 6.1 General Software Project Organization Project Management Database Management Application Design Build/Packaging User Interface Design Application Management Tools Support Requirements Analysis Applications Testing Process and Measurement System Design Systems Testing Publication and Information Design Publication and Information Development

7. Software Development Structures • Refining the General Organizational structure • Matrix vs. Hierarchical Orientation • Functional Orientation • Highly Specialized Organization

8. Matrix vs. Hierarchical Orientation • The software development structure is flexible based on the size of the project. • The organization structure may be represented either as a hierarchy or as a matrix. • Hierarchy org.:all the people associated with a project are grouped into functional departments that report directly within the vertical line of command of the organization • Matrix org.: people are grouped based on the functions they perform. • Functions may be performed by non-members of official project organization • Less function duplication, better focus on specialized skill. • What about team loyalty and confusion?

9. Project Manager (Sally Thomas) Apps. Designer (John Chang) Project interface to prog center. (Mark Burke) Req. Analyst (Tom Shaker) Apps. Designer (Kim O’Conor) Project Interface to process & tools (to be hired) UI Designer (to be hired) Functional Orientation • The general orgl. structure may be further refined to show a more precise structure. • It is important that the org. be defined down to a level where each individual can see her/his name.

10. Software Development Manager (Sally Thomas) Senior Apps. software Engineer (Tom Shaker) Senior Apps. software Engineer (to be hired) Apps. Analyst (Tom Shaker) Apps. Engineer (to be hired) Apps. Engineer (Laura Lang) Apps. Engineer (to be hired) Apps. Engineer (to be hired) Apps Engineer (to be hired) Apps Engineer (to be hired) Highly Specialized Organization Software development specialization

11. Highly Specialized Organization • More specialized, that is the groups responsible for only the development of software, but not the information development and publication task. • Group does not perform any of the requirements gathering and specification activities, nor does it handle any independent testing.

12. Software Support Structures • Spmr must set up an extensive customer interface group, such as call service dept. that handles the following duties: • Answer calls • Analyze each problem • Respond to the customer if a possible solution exist • Generate a problem report when an immediate solution does not exist • Track problem resolution activities • Report and deliver solutions to the customer • Close problems

13. Software Support Manager Customer level 1 support leader Customer level 2 support leader Customer level 3 support leader Customer Call support analyst Problem resolution Analyst Software support Engineer Customer Call support analyst Software support Engineer Problem resolution Analyst Customer Call support analyst Problem resolution Analyst Software support Engineer Software Support Organization

14. Recruiting and Hiring Software Personnel • Once the organizational positions are outlined, the software project management needs to fill open positions. • The actual hiring of the employees starts with having a clear definition of the open position in terms of the skills, training, and character of the candidates required for each position. Recruiting: • It is usually not sufficient to provide a general description of the position title to the HR department.

15. Agenda • Organizing (POMA) • Organizing • Human resources • The Project Team

16. Project Team Life Cycle • Very few projects can be completed by individuals. • Group becomes a team through proactiveefforts by members and project manager. • Typical project team life cycle goes through three stages: • Team formation • Team development • Team maintenance

17. Project Team Life Cycle • Teams need forming, developing and maintaining • Amount of management activity differs at different stages of the team life cycle. Developing Forming Maintaining Relative management Effort Team Stages

18. Project Team Life Cycle • Team building activities center on education and training on areas like: • Building trust • Negotiation skills • Listening skill • Responding to pressure • Project manager must ensure that there is enough time in the project schedule for such training.

19. Team Formation • Having the best people does not guarantee success unless experts work effectively as a team. • Project might be delayed or fail due to personnel conflicts. • Tasks may be independent but interrelated.

20. Team Formation • Project manager will review tasks and decide on the skills required to complete them. • Team members should possess other behavioral characteristics or “soft skills”. • No perfect person exists, managers should not look for mythical candidates.

21. Technical Software skills • Technical skill • A specialized skill in a subject that is needed to perform the activities in that subject domain. Usually requires knowledge and training in a scientific, engineering, or business discipline. • The skill areas include: • Requirements solicitation and specification • Database design • Design, programming and debugging • Test design and test script writing

22. Soft skills and personal traits • Traditionally, managers tend to focus on technical skills and experience. • Managers should look for othercharacteristics, many of which are “soft skills” • Soft skills • A non-technical skill that can be utilized on multiple occasions and is not restricted to any specific domain.

23. Soft skills and personal traits • These personal traits might include: • Personal ambition • Interpersonal communication skill • Sense of urgency • Strongly held likes and dislikes • Attention to detail • Some team member may have negative personal traits. • E.g., Personal ambition over team goals.

24. Team Development • Project manager may need to intervene in the team’s adjustment process. • Changing team members • Dismissing participants

25. Team Development • Some key activities for project managers • Ensuring communication is taking place • Ensuring member are treated with respect • Ensuring clear understanding of roles and assignments • Ensuring the team is not harboring a chronic laggard • Ensuring members understand team goals • Ensuring that members follow the agreed-upon process

26. Team Development • To promote team building, managers may sponsor: • Off-site meetings • Motivational speakers • Team games, e.g., softball • Team presentations • Remembering birthdays • Group events create strong bond through trust • Member can relate experience to need for interdependence in software project.

27. Team Development • Team members behavior need to be continuously monitored • Project managers should perform conscientious socializing • Informal data gathering to pick up any signs of team disorder (e.g., non-return of emails). • With remote and virtual teams • Communication is a major source of team related problems. • Members may need counseling on basic working etiquette

28. Team Development • Team or personal Issues • One or more people are upset about something and its negatively impacting the team. • E.g., personal (“I can’t stand working with Fred”) • E.g., systemic (“I hate how we do code reviews”) • Start by talking one-to-one to people involved • Ask what is going on and what can be done? • Seek out causes not just symptoms.

29. Team Development • The disagreement is preventing progress. • Seek mutuallybeneficial outcomes (do not compete) • Find a point of unification (e.g., project need to be on time) • Don’t let personality traits distract you from the goal. • Force people to talk about interests (not positions) and reach agreement • Be strong but supple • Know points of flexibility • If you can give more time, can you allocate more money?

30. Team Maintenance • Rewarding team members • Punishing team members • Handling team attrition • Team member growth

31. Agenda • Organizing (POMA) • Processes, Methodologies and Tools • Organization of Process

32. Processes • In addition to hiring new employees, other new resources necessary for the software project must be considered, acquired, established, and installed during the organizing phase. • The process used to develop the software must be clearly defined.

33. Processes • The process must be tailored depending on some of the following: • The size and complexity of the project based on the deliverables • The maturity of the organization • The history of the working relationships of the people • The size of the organization • The goals of the software project

34. Process Map • There is a need to map the overall process to clearly list the activities carried out with in each step, and to explain any relationships among the steps. • Diagram: • For waterfall-like process • Arrows show the flow of activities. • Dotted arrows indicate the potential for backward flow.

36. Process Map • The conditions for the successful completion or the exit criteria of a step, which allow the work flow to continue to the next step, need to be provided as a companion to the process map. • Typical exit criteria from the design process: • All the functional and nonfunctional reqs. are designed including the following: • The systems and communication interfaces • Database and file structure • Special constraints: performance, security, backup/recovery, etc.

37. Process Map • Typical exit criteria from the design process cont: • All of the design is documented and represented in the preciously specified format and language. • The design document is stored in a configuration management tool. • The design document is reviewed and all errors found have been fixed and captured in the updated design document. • The defined exit criteria for the process steps provide a management and a team approach to controlling the flow of activities.

38. Processes Configuration Management • Defn: A set of procedures that define, track, and control artifacts produced during the development, support, and maintenance of software.

39. Processes Configuration Management • Configuration management is made up of a complex set of activities including the following key activities: • Part 1: Definition and Setup - Defining and listing the artifacts that need to be managed - Defining the granularity of managing the artifacts and designing the directory scheme to accommodate that level if granularity - Defining the rules for accessing the artifacts

40. Processes Configuration Management cont • Part 2: Control and track - Defining the security and controls needed to manage the artifacts • Storing retrieving, locking, and unlocking artifacts based on the predefined rules • Maintaining all of the tools employed to help in configuration management. • Note configuration management spans the entire project.

41. Processes Process Introduction and Education • Members of a project team may come from a variety of backgrounds, all of which use some form of a process. Even if this process is some form of chaotic organization i.e., the process is formulated as the project progresses. • Education and communication of project progress should come instages. • There are many approaches, one such approach is as follows:

42. Processes Process Introduction and Education • Stage 1: Process Introduction • Provide the intro and education, if necessary, to the general process chosen for the project. • Provide the rationale behind the specific process. • Point out both the positive and the negative as well as any portion of the process that is still untested. • Point out any past history, if available.

43. Processes Process Introduction and Education • Stage 2: Feedback and Modification cont • Allow team members to debate and study the process on their own. • Ask for written feedback. • Collect and analyze the responses • Make appropriate modifications and prepare for responses to these changes. • Bring the team together, providing the team members with feedback on which suggested modifications were accepted and explaining what was done with both the accepted and the rejected suggestions.

44. Processes Process Introduction and Education • Stage 3: Acceptance • Ask whether any further education is needed and provide it as appropriate. • Ask for concurrence and acceptance of the process. • Stage 4: Reinforcement • Quickly review the process and ask for any further input to its implementation. • Make any adjustments and update the process as needed.

45. Processes Process Introduction and Education • The effort required to organize, communicate, educate, and gain acceptance of the process may be longer than many people would like. • Stage 4 (reinforcement) may be performed repeatedly as needed, but not excessively. • As new employees come on board, they must also be introduced to the project process. • Spmr needs to ensure that the team is clear about, and ready to follow the process map.

46. Methodologies • Methodology is a prescribed set of steps to accomplish a task. • The process provides the macro steps the methodology provide the microsteps, i.e., the difference between a methodology and a process is a matter of degree. • Spmrs have traditionally been highly involved in discussion on methodologies for the following reasons: • Need to keep up with the new methodologies • Promotion was linked to performance using a methodology

47. Methodologies • Spmrs must be familiar with the most appropriate methodology. • Spmrs need to monitor how the methodology is used on the project. • The spmr needs to ensure that the team is prepared to use the methodology. Usually describe at two levels: • Higher-level is a more process oriented way i.e., major substeps to be employed are listed and their relationships shown. • Deeper level describes the specific methods in each substep.

48. Tools • Tools should reduce work and increase productivity and efficiency. • Tools represent a significant set of resources for software projects. • There have been claims of 50% - 200% gains in productivity as evidence of a particular tools’ effectiveness. On the other hand the expected savings for some tools did not materialize. • Spmrs should take a realistic note of what should be expected and what effort will be required to achieve the expectation.

49. Tools Tool Identification and Preparation • Some activities the manager should carry out to prepare for the acquisition and use of the tool: • Identify the specific steps and activities that the tool is expected to automate or improve. • Explore realistic expectations for the tool, stated in terms of productivity gain or efficiency gain that the automation of these steps will bring. • Review the various tools available that will meet these expectations. • Review the training needed to attain the level of competency for the expected gains.

50. Tools Tool Identification and Preparation: • Choose the specific tool to be acquired, working out the needed terms and conditions. • Announce the decision. • Set and communicate the realistic expectations in terms of productivity gains that the team should be experiencing. • Schedule and facilitate the necessary training. • Acquire and set up the chosen tool. • Ensure the proper continuous support of the tool is in place. • Communicate the project policy for usage of this tool • Set up the mechanism to enforce the usage policy.