1

Project management in SE

Methodologies and models of software processes

Peeter Normak

26.11.2015

2

Plan

1. Discussion: Home assignment.

2. Choice of a software development methodology.

3. Examples of methodologies/models.

4. Capability maturity models (CMM-SW and CMMI).

5. NASA software process improvement methodology.

6. Software process assessment methodology SPICE.

7. Reviewing project proposals.

8. About the examination.

9. Reflections

3

Home assignment

1. Formulate three words of wisdom based on the article “Why Software Fails” (http://spectrum.ieee.org/computing/software/why-software-fails/).

2. Find at least five myths about software development.

3. What do you have learned at most from NASA SEL experience (http://www.cs.umd.edu/~basili/publications/proceedings/P94.pdf)?

4

SW development methodology – what it is?

A software development methodology is a framework for structuring, planning, and controlling the process of software development.

A software development methodology is a splitting of software development processes into distinct phases containing activities with the intent of better planning and management.

A software development methodology is a way of organizing and managing the development of a piece of software.

A software development methodology is a collection of procedures, techniques, tools and documentation for supporting the software developers in developing and implementing a new software.

5

The classical waterfall model

6

The waterfall model and a two-phase model

Requirements Design Coding Testing Implementation

The advantages of a two-phase model:• gives an opportunity to interrupt a project after relatively few costs are

made, if it turns out unreasonable to be completed.• allows to plan a project more adequately (because activities and costs are

planned in two phases).• motivates the project managers to turn more attention to project planning.

7

The waterfall model – economic characteristics

1. Correction of an error that was made during the design phase at the implementation phase of the project is hundred times more expensive than it would be corrected immediately.

2. Programming (coding) consumes only 15% of software development costs.

3. By reading the code only 60% of errors can be detected.

4. Pareto principle is applicable in software development as well: 80% of problems are caused by 20% of elements (80% of activities to 20% of requirements; 80% costs to 20% of components; 80% errors in 20% of components; 80% of results achieved by 20 % of developers etc).

8

Multi-stage (iterative) development model

The general structure of the model:

• The first phase: requirements and architecture/general design.

• Stage 1: detailed design, coding, testing, integration and release

• Stage 2: detailed design, coding, testing, integration and release

• …

• Stage n: detailed design, coding, testing, integration and release

• Final release of software.

9

Discussion

List some advantages of the multi-stage

development model.

10

Advantages of the multi-stage model

1. Early introduction of software.

2. Risks are decreased.

3. Problems appear in the early phase.

4. Time for composing reports decreases (working software is the best report).

5. More possibilities/choices for increasing functionality.

6. Planning is more adequate (feedback after every stage!).

7. Better flexibility and efficiency of software process (changes are discussed after each stage).

8. Correction of errors is more effective (localisation is much easier).

9. Work distribution is more even throughout the project life-cycle.

11

Agile SW development methodologies

12

Agile development methodologies – the basics

A number simultaneously developed methodologies appeared mid 1990-ies.

Most well-known: extreme programming (XP) and Scrum.

Most well-known person: Kent Beck, initiator of Manifesto for Agile Software Development (1996).

Key words: Communication, Simplicity, Feedback, Respect, Courage.

XP roles: developer, customer, coach, tracker; tester, consultant, big boss.

Scrum roles: The Product Owner, Scrum master, team member.

13

Agile development methodologies – specifics

Specifics:

• discipline,

• high and broad qualification,

• small development teams,

• change of requirements is possible throughout the whole project,

• effective usage of human work.

See, for example, the Wikipedia article “Agile software development –

https://en.wikipedia.org/wiki/Agile_software_development

14

Agile development methodologies – some technics

1. Bases on user stories, realization of a story 2 weeks in average.

2. Changing roles and tasks in development.

3. Every day starts with a stand-up meeting.

4. Minimality principle (add new functionality only if really needed).

5. Intense and continuous collaboration with the customer.

6. Agreed rules, specifications, standards.

7. Pair programming.

8. No overtime work!

See http://www.extremeprogramming.org/rules.html

15

Agile development methodologies – some risks

1. Less documentation does not mean complete missing of documents.

2. All team members are not good enough in completing all tasks.

3. Product owner can not represent the interests enough of all stakeholder.

4. The fact that there are no project managers can cause problems in work distributions (the teams are self-organizing).

5. Predefined duration of sprints can cause quality problems (in cases when, for example, the testing turns to be more complex).

16

Combination of principles (on example of Scrum and PRINCE2)

“Implementing lean is also a lean process, an iterative process of change, learn and adapt”.

Scrum is output-based (processes are flexible), PRINCE2* is process-based.

Basic processes: • Starting up a project (the only pre-project process)• Initiating a project • Directing a project • Managing stage boundaries• Controlling a stage • Managing product delivery Scrum• Closing a project.

* http://www.projectsmart.co.uk/docs/prince2-introduction-ps.pdf

17

Scrum + PRINCE2 – synergy

PRINCE2 strengths:

• Project Board can represent the interests/needs of stakeholders better than a single person (Product Owner).

• Project Manager has authority to coordinate the project activities.

• Risk management is a pre-defined PRINCE2 process, but not regulated in Scrum.

Scrum strengths:

• Description of the intended outcome will evolve during the project execution.

• Starting new tasks/sprints without waiting permissions from the Project Board.

• Lesson Learned document will be updated at the End of each sprint.

18

Recommendations: Choice of a software development methodology

1. Competent usage of a method is more important than the method itself. Therefore, implementation of a new method should be justified and could be performed after a thorough analysis only.

2. Experience of implementing a new methodology obtained in other institutions may prevent dramatic failures.

3. A methodology should be adapted to the organizational culture as well as to the skills and habits of the project team; a majority of the team should accept the (adapted) methodology. Example: Cramo.

4. The development and other tools depend sometimes from software process methodology. It is suggested to use three level division in usage of the tools: compulsory, recommended, acceptable.

19

Discussion

Whether to use the term “software development method”

instead of “software development methodology”?

See: Geambasu, C.V., I.Jianu, I.Jianu, A.Gavrila (2011). Influence factors for the choice of a software development methodology. Accounting and Management Information Systems 10 (4), 479-494.

ftp://ftp.repec.org/opt/ReDIF/RePEc/ami/articles/10_4_3.pdf

20

Maturity models of SW development

21

Capability Maturity Model for Software CMM-SW

For assessing the quality of an institution in software development.

5 levels: initial, repeatable, defined, managed, optimizing (distribution is very uneven!).

Each level has key process areas, requirements and self-evaluation questionnaire.

2003 analysis in Estonia (69 respondents): no company has reached the level 2!

Recommendation (Gunnar Piho): consider sub-levels of level 2 : • CMM2-requirements (requirements are well managed)• CMM2- plans (CMM2-requirements+activities are planned and resourced)• CMM2-results (CMM2-plans+monitoring of activities/results).

22

CMM-SW – 2nd level questions about SW project planning

1. Are estimates (e.g., size, cost, and schedule) documented for use in planning and tracking the software project?

2. Do the software plans document the activities to be performed and the commitments made for the software project?

3. Do all affected groups and individuals agree to their commitments related to the software project?

4. Does the project follow a written organizational policy for planning a software project?

5. Are adequate resources provided for planning the software project?

6. Are measurements used to determine the status of the activities for planning the software project (e.g., completion of milestones)?

7. Does the project manager review the activities for planning the software project on both a periodic and event-driven basis?

23

Discussion

Possible shortcomings of the

Capability Maturity Model for SW (and capability models in general)

24

Capability Maturity Model Integration – CMMI

The purpose: provide guidance for improving organization’s processes and ability to manage the development (CMM-DEV), acquisition (CMM-ACQ), and service provision (CMM-SVC).

CMMI bases on process models. Process areas are: 1)Project management2)Process management3)Supporting processes (analysis and quality assurance)

Capability levels 1…5.

The components of a CMMI model are grouped into three categories that reflect how they are to be interpreted: •required (Specific goals and generic goals of an institution), expected (Specific practices and generic practices) informative (provide details that help model users get started in thinking about how to approach goals and practices).

25

Example: CMMI – processes for development

1. Project Planning (2)2. Requirements Management (2)3. Quantitative Project Management (4)4. Risk Management (3)5. Integrated Project Management (3)6. Project Monitoring and Control (2)7. Organizational Process Definition (3)8. Organizational Process Focus (3)9. Organizational Performance Management (5)10. Organizational Process Performance (4)11. Organizational Training (3)12. Causal Analysis and Resolution (5)13. Configuration Management (2)14. Decision Analysis and Resolution (3)15. Measurement and Analysis (2)16. Process and Product Quality Assurance (2)17. Supplier Agreement Management (2)

Additionally for level 3: Product Integration, Requirements Development, Technical Solution, Validation, Verification.

26

CMMI Capability and maturity levels

Level 0 (incomplete): a process that is either not performed or partially performed. One or more of the specific goals of the process area are not satisfied.

Level 1 (performed/initial): a process that satisfies the specific goals of the process area.

Level 2 (managed): a process that is planned and executed in accordance with policy, employs skilled people having adequate resources to produce controlled outputs, involves relevant stakeholders; is monitored, controlled, reviewed, and evaluated.

Level 3 (defined): a process that is tailored from the organization's set of standard processes according to the organization’s tailoring guidelines, and contributes work products, measures, and other process-improvement information to the organizational process assets.

Level 4 (quantitatively managed, for measuring maturity only): a process that is controlled using statistical and other quantitative techniques.

Level 5 (optimizing, for measuring maturity only): process that is changed and adapted to meet relevant current and projected business objectives; focuses on continually improving the process performance through both incremental and innovative technological improvements.

27

NASA Software Process Improvement (SPI) methodology

NASA SPI methodology is iterative and relative (based on the current level).

Understanding: Specification of objectives and possible processes, models, relations and

indicators for achieving these objectives (the goal is to understand what processes can lead to the objectives).

Assessing: Assessing the impact of applying different methods and tools (the goal is to find

methods and tools that are most suitable to apply).

Packaging: Implementation of the most suitable methods and tools in the organization’s

everyday practice.

28

NASA SPI versus CMM-SW

The most significant differences between NASA SPI and CMM-SW:

1. About the conception: NASA – bottom-up, CMM – top-down;

2. Scope: NASA – based on concrete needs, CMM – general process quality;

3. Assessment: NASA – relative with individual indicators, CMM – absolute with universal indicators;

4. Scale: NASA – continuous, CMM – 5 levels.

Several NASA SPI basic principles are realized in CMMI.

29

SW assessment processes

30

Software process assessment methodology SPICE

Software process assessment methodology (Software Process Improvement and Capability dEtermination): a framework for the assessment of software processes.

It:• Facilitates self-assessment• Takes account on the context of the process being assessed• Produces a process rating profile rather than a pass/fail result• Addresses the adequacy of practices relative to the process purpose• Is appropriate across all application domains and sizes of organization.

Is approved as ISO/IEC 15504 “Information technology – Software process assessment” standard.

31

SPICE – the initial structure

1. Concepts and introductory Guide.

2. A model for process management. Defines, at a high level, the fundamental activities that are essential to software engineering.

3. Rating processes. Defines a framework for conducting an assessment, and sets out the basis for rating, scoring and profiling process capabilities.

4. Guide to conducting assessment.

5. Construction, selection and use of assessment instruments and tools.

6. Qualification and training of assessors.

7. Guide for use the results of an assessment in process improvement.

8. Guide for use in determining supplier process capability.

9. Vocabulary.

32

Standard ISO/IEC 15504 “Information technology – Software process assessment”

1: Concepts and vocabulary (ISO/IEC 15504-1:2004)

2: Performing an assessment (ISO/IEC 15504-2:2003)

3: Guidance on performing an assessment (ISO/IEC 15504-3:2004)

4: Guidance on use for process improvement and process capability determination (ISO/IEC 15504-4:2004)

5: An exemplar Process Assessment Model (ISO/IEC 15504-5:2012)

6: An exemplar system life cycle process assessment model (ISO/IEC 15504-6:2008)

7: Assessment of organisational maturity (ISO/IEC 15504-7:2008)

8: An exemplary process assessment model for IT service management (ISO/IEC 15504-8:2012)

9: Target process profiles (ISO/IEC 15504-9:2011)

33

Composing recommendations

34

Reference (recommendation)

The aim: to get an opinion from a competent person representing a target group, about necessity and usefulness of the project outcome.

Choosing the person for writing a recommendation: the person should be an expert in the field the person should not have a conflict of interests the financing institution should accept the person.

Normally the content will be disclosed to the project team. E: KN Cambridge

Sometimes the recommendations are form based dealing with some fixed aspects only. E: assess the competence of the applicant.

Problem: recommendations tend to be quite formal and are sometimes almost useless. E: Tiger Leap.

35

Recommendations (composition of recommendations)

1. The text of a recommendation should be concrete and objective, contain relevant facts.

2. Recommendation should contain information about the aspects that are important for the financing institution.

3. Describe possible/expected benefits that the outcome of the project can bring.

36

Reviewing project proposals

37

Reviewing the project proposals

The aim: to get an assessment about suitability of the project (from the point of view of the financing institution).

Some aspects (the concrete list depends on the financing institution): To what extent the project corresponds to the priorities and aims of the

financing institution, Are there enough resources for executing the project; first of all, the human

resources: are the people competent enough. How realistic is the timetable, How adequate the budget is; how effectively the resources will be used.

NB! The reviewer should check correctness of all citations and calculations. E: discussion in Pärnu.

What threats and negative consequences may the project have.

38

Recommendations (reviewing – view of a project team)

1. Be not too critical with respect to what has been done so far by other institutions/individuals (in justification of the need of the project). E: SF article – Anh.

2. Take into account that reviewers are normally experienced experts (do not bluff).

3. Take into account that reviewer may not be an expert in all aspects of the project – the text should be clear and unambiguous.

4. Use preliminary (maybe in-house) reviewing.

39

Recommendations (reviewing – view of a reviewer)

1. Be benevolent and constructive in reviews (rather than suspicious and grouchy).

2. Be careful and thorough because the quality of reviews is one of the tools for building up of experts’ reputation.

3. Consider the possibility of reviewer’s identity disclosure.

40

Example: evaluation criteria I

Evaluation criteria for training projects targeted to school teachers.

1. Whether and how is the project related to national school curriculum?

2. Does the project contribute to the development of education in Estonia and when the results can be expected?

3. Are the outcomes of the project applicable in majority of Estonian schools (that is, are there necessary technical and human resources available)?

4. Is the budget realistic?

5. Is the timetable realistic?

6. Is the project team qualified enough?

7. What negative consequences may the project have to Estonian schools and educational system?

8. Evaluation of training materials.

9. Practical conducting of the training.

10.The accuracy of the drafting of the text of the application.

11.Grade the project proposal in the ten-point scale.

41

Example: evaluation criteria II

Grade 10: excellent (extremely actual, best possible teachers, project application is thoroughly elaborated, budget is adequate). Application to be approved in full amount, without any changes.

Grade 8: very good (actual, high level teachers, project application is thoroughly elaborated, budget is adequate). Application to be approved, possibly with some minor changes.

Grade 6: satisfactory (actual, competent teachers, project application is satisfactory elaborated, budget is adequate). Application to be approved, taking into account the changes proposed by experts.

Grade 5: conditionally satisfactory (actual, competent teachers, project application is satisfactory elaborated). Resubmit the application, taking into account the changes proposed by experts.

Grade 4: poor (not actual or teachers not competent enough or project application is unsatisfactory elaborated). Reject the application.

Grade 2: extremely poor (not actual, teachers are not competent enough, project application is unsatisfactory elaborated). Reject the application, resubmission of a revised application inadvisable.

Grade 1: out of scope (this type of training projects will not be supported).

Weighted average grade is possible; Financing can be made subject to satisfaction of certain conditions.

41

42

The examination

43

Submission of documents – the dates

1. 10.12 – presentation of examination documents (group work):• Project Plan

• Final Report

• Analysis Document

2. 15.12 (the deadline) – Submission of the examination documents (group work).

3. 31.12 (the deadline) – Submission of a review and 3 assessments (exactly three major strengths and three major weaknesses for each assessed work) (individual work).

All documents should be sent to peeter.normak@tlu.ee

44

The documents – general requirements

1. Examination work (Project Plan, the Report, the Analysis Document) should be original, composed specially for this course.

2. The text of examination work should be well structured, relevant, focused, without superfluity. Describe the role of each student in in each document.

3. Review and assessments should be in a single file. The name of the file should begin with the name of the author, followed by “review_assessments”.

Example: JaanTamm-review_assessments.doc.

45

Examination work – the Project PlanGroup work

46

Composition of a project plan

1. Project plan should cover possibly all important aspects.

2. Budget is compulsory even if no real money is needed for conducting the project. The budget should base on estimation of necessary resources (workload, depreciation, expert advice etc).

3. In case the project plan is form based – preferably not – and an important aspect of the project does not fit into the form, this information should nevertheless be included either into an existing section or into an extra created section.

47

Project Plan – the structure

1. Base on slide “Structure of a project plan” in the “PM-project-planning-2015.ppt” presentation.

2. Do not restrict with the aspects indicated explicitly in the brackets of a unit (for example – need, previous experience).

3. Add additional sections depending on the type of the project. Examples of aspects that can be covered: slide “Project plan – additional aspects” in “PM-project-planning-2015.ppt”.

4. If a section (for example, the needs analysis) of a project plan is disproportionately large then it (or part of it) can be formed as an appendix.

48

Project Final ReportGroup work

49

Final report – the structure

1. Base on slide “Final report – the structure (Example)” in the “PM-project-completion-2015.ppt” presentation.

2. The figures on this slide are indicative.

3. The report can have different structure, depending on the project.

4. Composing the text, take into account the general quality indicators (described on slide “Final Report – quality indicators” of the “PM-project-completion-2015.ppt” presentation).

5. If a section (for example, the needs analysis) of a project plan is disproportionately large then it (or part of it) can be formed as an appendix.

50

Final report – possible additional sections

1. Impact assessment.

2. Dissemination

3. Exploitation

4. Cooperation with other institutions

5. …

Example: Final Report of the HITSA project “Development of Interaction design studies and research in Tallinn University” (file Final_Report-IDLab-2009-2012.pdf)).

51

Analysis documentGroup work

52

Analysis document – the structure

1. Base on slide “Analysis document” in the “PM-project-completion-2015.ppt” presentation. Discuss additional aspects if necessary.

2. Do not merge with the Final Report: the common part should be as small as possible.

3. Be flexible in dividing the text between the Final Report and the Analysis Document: if, for example, recommendations fit better in the Analysis Document, put it there.

53

Analysis document – the content

1. Express all opinions of the Project Team in the document, even if these are opposite/contradicting to each other.

2. The quality indicators of the Final report (slide “Final Report – quality indicators” of the “PM-project-completion-2015.ppt” presentation) are applicable to the Final Report as well.

3. The Analysis Document should harmonize with the Project Plan and with the Final Report. For example, if the project outcome differs from this initially planned, the reasons should be discussed in the Analysis Document.

54

General recommendation

It is recommended to ask somebody from outside the project team to read and analyse the Project Plan,

Final Report and analysis Document before submitting.

55

Review and assessmentsIndividual work

56

Review

1. Take into account suggestions presented in the Lecture Notes (also in “Reviewing project proposals” in this presentation). Judge also about the novelty in evaluating project plans.

2. Review should not just be short description of the analyzed work, but a critical analysis.

57

Three strongest and three weakest aspects

1. Exactly 3+3 aspects should be described and explained. Even if the evaluated work seems to be perfect, there are always aspects that can be improved (for example, not based on some existing formal model or on a conceptual framework, links to national on other strategic development plans not discussed, superficial initial study or risk analysis, target groups not defined etc).

2. Be as specific as possible. For example, write “Unemployment insurance tax is not taken into account in calculating the budget” instead of “Budget is not correct”.

3. Evaluate the examination work, not the object of the examination work.

58

Presentations

59

Presentation – organization

1. Duration – 20 minutes:• Project Plan – 5 minutes (name, team, objective, needs, activities)

• Final Report – 5 minutes

• Analysis – 5 minutes

• Discussion & evaluation – 5 minutes

2. The presentation – from a laptop of a team member.

3. Each team member should have a word.

4. Take into account the assessment criteria (next slide).

5. Assessment on 10 point scale – anonymous.

60

Assessment criteria

1. The objective – topicality, SMART criteria.

2. The approach/work plan – originality, logical structure, risks.

3. Project execution – work division, problem solving, outcome.

4. Presentation – understandable, attractive, visual solution.

5. Discussion – questions, responses.

6. Added value – new knowledge, usefulness.

Scores:10 – outstanding8 – very good6 – satisfactory4 – poor2 – extremely weak

61

Reflections

1. What problems did you face during the course?

2. The proportion General project management – Specifics of ICT PM: should it be changed in one or in another direction?

3. The proportion of discussions?

4. Which additional topics should be covered?

5. Which topics could be reduced?

6. Any other suggestions.

62

Next meeting:10th of December

Presentation of examination works

63

The most common SW failure factors (R.N.Charette)

• Unrealistic or unarticulated project goals

• Inaccurate estimates of needed resources

• Badly defined system requirements

• Poor reporting of the project's status

• Unmanaged risks

• Poor communication among customers, developers, and users

• Use of immature technology

• Inability to handle the project's complexity

• Sloppy development practices

• Poor project management

• Stakeholder politics

• Commercial pressures

64

NASA lessons learned (examples)

Lesson 1: Data collection requires a rigorous process and professional staff.

Lesson 8: Having a shared commitment over research and development is vital for success.

Lesson 9: There is a symbiotic relationship between research and practice in software engineering and both activities gain from the interaction.

Lesson 10. Close proximity of researcher to developer aids both.

Lesson 13: It is difficult to make an engineering organization aware of the importance of software engineering to their mission.

65

Myths about software development

Variety of different lists. Example: 32 UX myths – http://uxmyths.com/

1. Software development consists of programming. Modifications:• For software development, it is sufficient to have programming skills.• The project is 95% completed as soon the code is compiled.

2. The total number of man-months is a universal measure of the size of a software project.

3. Large development teams ensure better productivity.

4. Good development tools ensure quality improvement (“The very best technology never has as much impact as girlfriend trouble”).

5. Module reuse reduces the development costs.

6. Older SW developers are less flexible and less capable of learning.

7. The customer knows what he wants (people can tell you what they want).

66Source: http://www.prince2-ug.be/The-Process-Model

67

Shortcomings in using capability models

1. Assessment bases on analyses of documents not on the analysis of actual processes.

2. Base on fixed indicators and do not take into account specific conditions and features.

3. Not suitable for small companies: only 2,6% of small companies (up to 25 employees) were on level 5 in 2005 and 62,8% of the big companies (more than 1000 employees).

4. Consider the existence of processes (what to do) not how these processes are conducted (how to do).

5. Considers a topic under evaluation, apart from other processes of the company.