Project management in SE

1. Project management in SE • Basic principles of software projects • Peeter Normak • 12.11.2015

2. Plan • General requirements for software • Specifics of software projects • Critical success factors of software projects • Preliminary planning of a software project • Software project staffing • Requirements development • Quality,risk and change management • Co-operation with upper management • Software projects costs estimation • Release of software • Software process best practices

3. General requirements for software

4. Development trends of modern economy and society The structure and type of economical activities are changing: • The share of services compared to manufacturing sector is constantly increasing (1970 – 1:1; 2010 – 3:1; IBM: 1995…2005 – 28%  55%). • Internet is becoming the major environment for providing services. • Services are becoming more and more individualized (mass customization, co-creation).

5. ICT influences the whole society • The business models of enterprises and organizations are changing: • Production ecosystems emerge. Example: Opel (seat belts) • Economy globalizes. • Economic processes are more standardized and automated. • ICT has decisive role in implementing changes: • about half of the productivity increase is due to ICT implementations. • The potential yearly contribution to European GDP from achieving a fully functioning Digital Single Market has been estimated at EUR 415 billion. • E-skills are becoming ultimately important.

6. Discussion • What are the most general requirements for • modern software that makes its development complicated?

7. General requirements for software • Modern software should: • Operate on different platforms and with different hardware. • Be interoperable with a wide variety of other software. • Satisfy the needs of a wide – and non-homogeneous – user group. • Be easily adaptable to specific needs and changing environments (for example changing legislation and institutional regulations). General requirements for software projects are determined by the general requirements for software.

8. Specifics of software projects

9. Specifics of software projects – implications from general requirements Software should: • confirm to the standards, • be user friendly both visually (graphical design) and logically (correspond to the activity patterns of users), • be easily expandable, • support the main processes of application areas, • adequately react to deliberate (for example attacks) and inadvertent (for example power failure) disruptions.

10. Specificity of software projects – high failure rate Standish Group (figures are in percentage):

11. Action lines for responding to the problems • The main reason for emerging severe problems in software development – massive introduction of local and wide area networks in 1980-ies and 1990-ies. • Action lines: • Systematic analysis of software development process and development of a variety of software development methodologies and tools. • Development of ICT related specifications and standards. • Development of different frameworks (for example, SWEBOK) and capability maturity models (for example, CMM-SW). • Development of curricula recommendations. • Development of e-skills certificates and certifying institutions. • Professionalization of ICT (project) management.

12. Current policies in Europe responding to the problems • DIGITALEUROPE’s Vision 2020 (http://www.digitaleurope.org/DesktopModules/Bring2mind/DMX/Download.aspx?Command=Core_Download&EntryId=157&PortalId=0&TabId=353). • Digital Agenda for Europe (https://ec.europa.eu/digital-agenda/en/digital-agenda-europe-2020-strategy). • A Digital Single Market Strategy for Europe (http://ec.europa.eu/priorities/digital-single-market/docs/dsm-communication_en.pdf). • Future-proofing eGovernment for a Digital Single Market. • Opening up Education: Innovative teaching for all through new Technologies and Open Educational Resources (http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:52013DC0654&from=EN).

13. Critical success factors of software projects

14. Critical success factors of software projects • Fundamental: optimize (minimize) rework in software development. • The role of initial phase in planning where the most important decisions are made – the 10% indicator. • Critical success factors are to a great extent determined by the requirements for software on the one hand and on the available resources on the other hand. • Examples: Dippler (lack of resources). • NB!Some more process management during the initial phase of a project can avoid huge overspendings for correcting mistakes in a final phase of a project; problems should be solved immediately!

15. Critical success factors of software projects • Examples (for another study, see Appendix 2 of the Lecture Notes – Aspects of ICT Project Management): • User involvement during the whole project. • Effective change management. • Quality assurance. • Timely integration of components. • Adequate corrections of time-table. • Following a suitable process model. • Support of the upper management.

16. Preliminary planning of a software project

17. The three main questions (view of a developer) • Planning costs of a project are normally 5-10% of the total costs of a project. • Before making the bid decision, answer the following questions: • Our bid will win because … (allows to stress on the strengths), • If our bid will not win, it will be because … (allows to eliminate the possible weaknesses), • The top three risks are … (allows to mitigate the risks).

18. Discussion • What aspects for making the bid/no bid decisions would you consider?

19. Making the bid/no bid decision (Smith, 2001) • Clarity of requirements. • Consistency with the strategy of the applicant. • Previous cooperation with the customer. • Existence of modules that are suitable to use in the project. • Existence of staff with necessary skills. • Availability of time resource for composing a high level bid. • Readiness of the customer to pay an adequate prise. • Prospects to win depending on the number of competitors and their quality. • The rate of differentiation from the competitors. • Ability to offer cheaper solutions compared to the competitors. • Opportunities to discuss the requirements, priorities, possibilities evaluation criteria and possible solutions with the customer.

20. The phases of a software process • The simplest model : • ADDIE (Analyse, Design, Development, Implementation, Evaluation) or, in more common terms in software development: • Requirements, Design, Construction, Testing, Implementation. • SWEBOK (The Guide to the SoftWare Engineering Body Of Knowledge): 15 knowledge areas + sub-areas (topics). • For example, Software Requirements has the following subareas among the 10 topics: • Requirements elicitation • Requirements analysis • Requirements specification • Requirements validation

21. Preliminary planning of a software project • The outcome of preliminary planning: a Charter. • The Charter should contain: • The vision of the project • The main authority/decision maker • The objectives of the project • The main risks • Needs in personnel • Estimated duration of the project.

22. Uncertainty coefficients for duration of a SW project • If the objectives of a project are concretized during the project then duration should be adjusted as well. • Example: uncertainty coefficients (according to NASA SEL): • c 1/c • After specification of requirements 2,0 0,5 • After requirements analysis 1,75 0,57 • After general design 1,4 0,71 • After detailed design 1,25 0,80 • After coding 1,1 0,91 • After testing 1.05 0,95

23. Software project staffing

24. Software project staffing – the work distribution • Need for a staff depends on the development model. Requirements analysis requires usually more time and higher qualification  some models do not include this phase, considering it separately. • Fred Brooks suggestion (distribution of man months): 1/3 planning, 1/6 coding, 1/4 component test, 1/4 system test. • Brooks’ law: “adding manpower to a late software project makes it later”. • Replacement of a developer during a software project is very costly  forming and keeping the staff is one of the quality indicators of project managers. • Problem: non-compliance of knowledge, skills and practices. • Example: GP master thesis – quality assurance.

25. Software project staffing – the roles • Different development models consider different roles of software project team members. • Example (Belbin’s role model, http://www.belbin.com/about/belbin-team-roles/): • Co-ordinator • Shaper • Plant • Monitor Evaluator • Implementer • Teamworker • Resource investigator • Specialist • Completer Finisher

26. Software project staffing – recommendations • Plan only up to 75% of available resources (including personnel). • Invest rather to an expert than to a “cheap” beginner and hope in his training and development (difference 10x in productivity, 5x in speed). • Harmony of the project team is more important than individual knowledge/skills; insufficient handling of tensions is the most often complaint of staff members. Belbin: balance – not intellect – enables a team to succeed. • Personality characteristics are more important than knowledge/skills: the latter are easier to form (Roger Woolfe, 10:6). • Project manager should be free in forming the project team; pressure should be avoided. • The roles that are formed in some other context should not inhibit the roles distribution in the project. • Example: student projects in Victoria University (Melbourne).

27. Requirements development

28. Requirements development • A software requirements: a description of a software system to be developed (may include also some use cases that describe interactions the users will have with the software). • Requirements are divided into functional and non-functional requirements. • Standish Group: The quality of requirements is in importance the 3rd success factor, and the 3rd failure factor. • Fundamental: user involvement (and therefore, identification of the key end users). Recommendations: http://www.mitre.org/publications/systems-engineering-guide/se-lifecycle-building-blocks/requirements-engineering/eliciting-collecting-and-developing-requirements

29. Requirements development – possible problems • The objective of a project is formulated in very general terms. Possible activities (PA): definition of related processes and concrete specification of requirements; composition of user stories. • Definition of users that will be involved in development. All important profiles should be represented. Example: registration to the courses. • Finding common language with the users. PA: training, seminars. • User awareness of their needs. PA: interviews, composition of user stories. • Ensuring effective usability. PA: style guide, prototypes, user manual. • Requirements change during the project. PA: using agile methodologies, effective change management.

30. Quality, risk and change management

31. Quality assurance • The influence of quality extends far beyond the End of a project  quality is much more important than time overruns. • Some important aspects: • The tests of an integrated system should be performed by people not belonging to the developers team. • Pareto rule (80:20) normally applies. Problematic modules should be found as early as possible. • Determine when to stop testing (for example, by the timely distribution of errors or by the formula N*M/L). • Procedures for correcting errors should be established (corrections should not cause new errors, automated testing etc).

32. Risk management • Risk management can be considered as solving of some kind of optimization exercise; in average 5-10% of the costs. • Follows general risk management schemes. The specific IT risk management activities include: 1) risk monitoring, 2) pricing of security measures, 3) monitoring of IT processes, 4) information security incident management, 5) log analysis and evidence handling. • Standard: ISO/IEC 27005:2011  Information technology — Security techniques — Information security risk management. • Framework (example): Risk IT – A Risk Management Framework by Information Technology Governance Institute (ITGI). • Analysis (example): http://www.isaca.org/SiteCollectionDocuments/2015-risk-reward-survey/2015-it-risk-reward-barometer-report.pdf

33. Change management – the procedure • Project plan and other documents need continuous updating/adaptation. • An agreed scheme is necessary. Example: • Initiators of a change will compose and submit Proposal for a Changethat describes the reasons why changes are needed and what are the expected results when changes will be implemented. • The board forwards the proposal for acceptance and improvement suggestions to the parties concerned. • The parties concerned will estimate the possible costs and benefits from their point of view. • Based on the feedback the board will make a conclusion and informs about it the parties involved. NB! All important document (risks, tests, style guide, delivery check list etc) should be the subject of change management.

34. Change management – topics to be considered • “Compulsory” topics: • Influence to the project plan: time-table, resource distribution (for example, increases the work load of busy people), quality etc. • Timing: are the changes timely (or should be postponed)? • Risks: affecting existing and emerging new risks. • The advantages of well organised change management: • Solutions used for software development are more broadly discussed and motivated. • The project is documented more completely. • The parties are better informed about each other activities.

35. Co-operation with the upper management

36. Co-operation with upper management – the need • Standish Group: Co-operation with upper management is in importance the 2nd success factor, and the 4th failure factor. • Effective co-operation assumes that the members of upper management are: 1) informed and 2) involved (the managers should get the feeling of ownership). • The following situations should be prevented: 1) Suspicions of the managers that the project is planned not quite adequately. Solution: all important aspects should thoroughly grounded and discussed with the managers. 2) The managers may make decisions that inhibit the project activities because they are not informed about the project’ needs (agreements of third parties, assigning important resources to other needs etc).

37. The aim of cooperation – getting support when needed • For doing a particular project or initiative. • For getting support in solving unexpected or serious problems (or even solving the problems). • For getting input from other projects or activities. • For launching cooperation with other institutions/stakeholders. • For getting involved/offering participation in new initiatives. • For focusing and speeding up processes (implementing bottom-up initiatives are normally time-consuming).

38. Co-operation with upper management – example • “Alcohol test”: the manager asks unexpectedly questions about important aspects of the project. • The objective of the test: to make sure that the team members have understood the project and their role within it. • Preventive actions are needed for successful passing the test: asking himself the possible questions, finding answers and discussion with the team members.

39. Software projects’ costs estimation

40. Software projects costs estimation • The model: Workload = SizeProcess × Staff  Environment  Quality • Size unit: 1000 lines of code or a function. Practices: reuse of components/code, automatic code generation. • Process. Practices: optimizing human work, reducing unnecessary work. • Staff: balanced team is better than individualistic high level experts. • Use less and better people. • Adjust the tasks to competences and motivation of the staff members. • Chose each other complementing and harmonizing people. • Help people to achieve self-realization. • Environment: development and other tools, techniques etc. • Quality: • Using suitable indicators/metrics. • Adapting mutually supportive work culture.

41. Release of software

42. Release of software • Procedures: • The distribution of errors has reached acceptable level. • All fatal errors are found and corrected. • Going through the release checklist. • Agree on the procedure for correcting the errors that are found after the project finishes. • Compose and discuss the history document. • Example. Release Management on Data Warehouses (Ronald Konings, http://www.konings.biz/thesis/Release%20Management%20%20Master%20Thesis%20v10.pdf). • Problem: rationality of beta-testing.

43. Release – recommendations • Forrester Research (2011): • Improve pre-build process (check the quality before the release; many problems have their root cause in early stages), • Expand release management throughput (use parallelism and intelligent testing processes); • Optimize release pipelines (implement virtualization, compress release cycles); • Design software for rapid change (improve system modularity); • Create common release portals (managers, developers and testers are informed about the updates). • Gartner (2013): release management process is insufficient or even completely missing in 95% of IT organizations.

44. Software process best practices

45. Recommendations I – Software process best practice • Present software to the customers as early as possible. No matter how much will you co-operate on the requirements analysis phase, practical work with the software is much more effective. • Use suitable process model. The model depends on the organizational culture of the institution, competence, elaboration of requirements, willingness to take risks etc. • Minimize the intellectual distance (between problem and solution, as well between the parties of the development). Structure of software should correspond to real world structures. • Make the program right before making it fast. It is easier to make working program simpler than a fast program correct

46. Recommendations II – Software process best practice • Good management is more important than good technology. Good technology does not compensate bad management. Good manager attracts good people and forms a devoted team. • Understand and follow the customers priorities. The customer agrees to get 90% functionality delayed if only the most important 10% will be delivered on time. • Software should allow changes. This applies both to the structure and components. • Software development should be self-documenting. The code must have a clear and clean structure, the names reflect their meaning etc.

47. Home assignment No 5 • Formulate three words of wisdom based on the article “Why Software Fails” (http://spectrum.ieee.org/computing/software/why-software-fails/). • Find at least five myths of software development. • What do you have learned at most from NASA SEL experience (http://www.cs.umd.edu/~basili/publications/proceedings/P94.pdf)?

48. Next lecture: • Thursday, 26. November • at 12:00 • Topics: • - Methodologies and models of • software processes • - Concluding discussions

49. Curricula recommendations • Association for Computing Machinery (ACM) and IEEE-Computer Society: http://www.acm.org/education/curricula-recommendations • The European Centre for the Development of Vocational Training (CEDEFOP): www.cedefop.europa.eu/etv/Upload/Information_resources/Bookshop/50/2204_en.pdf • European Quality Assurance Network for Informatics Education (EQANIE): http://www.eqanie.eu/pages/quality-label/framework-standards-criteria.php

50. E-skills development EU policy (“Technology for innovation/ICT industries and e-business”): NB! Directorate General Enterprise and Industry. European e-Skills 2006 Conference in Thessaloniki: “the success of the Lisbon strategy, the competitiveness of European industry and social cohesion are dependent on the effective use of ICT and the knowledge, skills, competencies and inventiveness of the European workforce and its ICT practitioners.” Developers Customers Users/stakeholders