MIS 518 – Term Project OM Decisions and Software Projects

1. MIS 518 – Term Project OM Decisions and Software Projects Turhan Atar Alp Eren Aydın Mehmet Nuri Can

2. 10 OM Decisions • Design of goods and services • Managing quality • Process and capacity design • Location strategy • Layout strategy • Human resources and job design • Supply chain management • Inventory management • Scheduling • Maintenance

3. MANAGING PROCESS QUALITY

4. Software quality is fundamental to software product success. • Yet quality as a concept is difficult to define , describe and understand • Quality has a strong subjective element • Quality experts including some with a software background have proposed models , not to measure quality itself but to measure surrogate attributes such that when combined can provide some notion of the quality of product

5. STANDART TYPES • ISO/IEC 9126 • CMM

6. ISO/IEC 9126 • ISO and International Electrical Technical Commision have developed ISO/IEC 9126 for Software Engineering • It is focusing on end product quality more than software process quality

8. Quality model framework of ISO/IEC 9126

9. CMM • There are some concerns were voiced both by customers and developers and were manifested in the following questions : • Why does it take so long to complete a software project ? • Why are the efforts so high? This in turn increases the cost. • Why can’t we ensure error-free software?

10. There was a need for a more disciplined effort in developing software. • The software engineering practices provided a framework for building high quality software. • Software Engineering Institute (SEI) developed a Capability Maturity Model (CMM) , which defined key performance areas from an initial level of maturity to a level of optimisation.

12. Software Process Quality Factor

13. Some of the organizations didn’t following any standards during software development and had problem with quality aspects of the software.

14. The software products need further improvement after released and unsatisfied customer with the quality or performance of the products.

15. The development of software certification model is beneficial not only to the users but also to the vendor and stakeholders as well.

16. Software certification can be implemented in three different approaches : product , process and people • Benefits : • Provides useful information that can prevent users that buying software that has doubtful quality level • A mechanism that can generate a form of confidence to customers

17. Can enforce discipline by encouraging the use of good software engineering practices and standards during development • An alternative approach for continuous software quality improvement • Enhancing and improving the quality and productivity of software development process

18. Most of the existing software certification models are directly focused on assessing and certifying software through its product quality approach. • Quality of software products should be evaluated separately from the software development process.

19. Many researchers believe product-based approach can give confidence to consumers about the quality of software. • Product based approach is hard to practice especially for the new software which just ready to be marketed or delivered.

20. Deming’s premise that «The quality of the product is largely governed by the quality of process used to develop it.»

21. Software Quality Factors • The role of software in human life is continuously increased and demanded, therefore software developers were competed to produce software faster and quicker.

22. A software project is considered failed if these factors exist

23. Software development methodology is important because it is to ensure the successful of development of products quality , increase productivity and ensure that the software had been developed in a cost effective manner.

24. Apart from technology and environmental factors, it is also necessity to focus on the quality of developers. • They are designing , developing, changing the system • Skills and creativity of the developers can give an impact on software process effectiveness.

26. The quality of developer can be measured in terms of skills, training and motivation. • Factors for determining the effectiveness of software processes were identified by four main factors • Human, Management, Economics , Technology

27. Key practices influencing the successful software development process

28. The factors identified through the state of theory and practice.

29. As we have seen factors were derived into several sub factors in order to easily defined the quality attributes or metrics and measures for each of them. • And for each sub factor , measurement goals, metrics and measure have been defined by applying the Goal-Question-Metric method.

30. Each goal contains one or several questions. • The question represents how each goal can be measured. • For each question , the metrics to be measured are defined and at least one measure is derived for each metrics. • The measure is used to determine appropriate quality achievement of each metrics.

34. Measurement Metric

35. Number of standards based on software process quality will increase

36. Staffing & Scheduling

37. Failures • 16% of software projects are on time and within budget (Lingberg, 1999) • 62 percent of IT projects fail to meet their schedules (Asay, 2008) • IS project failure reasons • Project managers don’t understand users’ needs. • The project’s scope is ill-defined. • Project changes are managed poorly. • The chosen technology changes. • Business needs change. • Deadlines are unrealistic. • Users are resistant. • Sponsorship is lost. • Managers ignore best practices and lessons learned. • The project lacks people with appropriate skills.

38. Knowledge and Capabilities • The necessity to find better ways to produce software products of high quality and within budget has lead to considerable research efforts investigating new means for improving an organisation's ability to plan, forecast, manage, implement, and control its activities in projects where people and their capabilities have a major impact on project performance and its quality. • In particular, the specific character of software tasks is such that, in many cases, tasks cannot be expedited (or in some cases even solved) by human resource reallocations or by adding extra resources. That is, software tasks are not resource-driven. These tasks cannot be defined as fixed-duration tasks because they are dependent first of all on people knowledge/skill capabilities which are different. The vast majority of software tasks are cognitively driven (self-managing intellectual work). • Contemporary approaches to resource allocation founded on the assumption that different jobs require equal capability resources, and only one skill is involved. Hence, they cannot be successfully used for software projects, where different software tasks require different sets of multiple knowledge/skill capabilities for a task performance.

39. Staffing Decision • One of the most critical factors driving the success of software projects: the staffing decision • As projects slipped behind schedule, managers would attempt to increase the staff at fairly late stages in order to speed up the project. However, employing more people would result in higher communication and training overheads, thereby affecting adversely the productivity of the existing staff, and setting the project back even further. • To assign right person to the right project is a complicated decision. Major contributors to the outcome of software projects are personnel assignment decisions

40. Staffing Decision • Managing software personnel remains a very complicated endeavor. A major contributor to this complexity is the increased demand for specialized individual skills in the workforce, which results from high turnover rates and the fast pace at which new technologies and techniques are being developed. As a result of higher demands, candidates with exact required skills to work tasks are usually not available. Due to the lack of proper methods to assess personnel capabilities, decision makers are forced to assign resources to tasks based on subjective measures only. This results in excess training times that significantly affect the schedule of projects. • Because a resource allocation methodology in software projects is not common and well-determined, most managers make allocation decisions in a highly subjective manner. Software managers typically make assignments based on ‘‘their experience, heuristic knowledge, subjective perception, and instinct"

41. Contemporary Project Management Models • Duggan, Byrne, & Lyons (2004) developed a multi-objective optimization model for software task allocation based on genetic algorithms. • Tsai, Moskowitz & Lee (2003) proposed selecting resources using the CRD method and the Taguchi’s parameter design approach. • Another methodology used to evaluate staffing alternatives is the Analytical Hierarchy Process (AHP).

42. Contemporary Project Management Models • Antoniol, Cimitile, Lucca, & Penta (2004) used queuing theory and stochastic simulation to study staffing needs for software maintenance problems. • Shaikh (1998) presented a model for project staff reallocation. The objective of the model was to increase the probability of projects finishing on time by avoiding delays caused by lack of needed work-force at scheduled start dates. The model, based on the Lead Time concept from Inventory Theory • Abdel-Hamid (1989) proposed a model to study the dynamic implications of staffing policies to the cost and schedule of projects.

43. Lack of Contemporary Project Management Models • Contemporary project management scheduling approaches cannot be sufficiently used for software projects. • They are concerned with resource availability and utilisation, and do not provide study, analysis and management of resource capabilities and compatibilities. • For the moment there is no widely accepted methodology for scheduling and staffing software projects. Nevertheless there are some models which have been desinged in the last years.

44. Mixed-Linear Program • Heimerl and Kolisch offers a mixed-linear program with a tight linear programming-bound for simultaneous scheduling and staffing multiple projects with a multi-skilled human workforce with heterogeneous and static efficiencies. • The objective function minimizes the labor costs of internal and external resources which accrue by processing the work packages of the projects.

45. Padberg’s Model • Padberg F. presents a generic model for software projects which explicitly takes a scheduling strategy as input. • No process modelling language is used in that model, just standard mathematical notations with a probabilistic approach. • When the scheduling strategy is fixed, the model outputs a probability distribution for the project completion time and a completion time estimate. • The model describes the software process at a high level of abstraction : teams work on, software components. • The intention is to keep the model as lean as possible for the time being and classical process phases such as coding or testing are not used in that model.

46. Best – Fitted Resource (BFR) • BFR methodolgy defines many inputs and allocate the resources to the projects by using linear programming. • There are 5 steps to describe those inputs and to find outputs; • Task Required Skills(TRS) – TRS Table • Skill Relationships(SR) – SR Table • Resources’ Skill Set(RSS) – RSS Table • Best-Fitted Resource(BFR) – BFR Table • Resource Allocation to Multiple Tasks (RA)

47. BFR • H: set of all skills • H(t): set of required skills for task t • ejt : expected use of skill j on task t. Assigned values range from 0 to 1 • 1 = highly used • 0 = not used • cjt: complexity of skill j on task t. Assigned values range from 0 to 1 • 1 = high level of complexity on the task for this skill • 0 = no complexity • sjt: significance of skill j on task t = cjp ejp. Calculated values range from 0 to 1 • 1 = critically important • 0 = not important

48. BFR • rjk: relationship between the level of knowledge of known skill j and the level of knowledge for required skill k. Assigned values range from 0 to 1 • 1 = strong relationship • 0 = no relationship • if j = k and the level of knowledge of both j and k are equal, then rjj =1 • lyj: level of knowledge of resource y for skill j. Assigned values range from 0 to 1 • 1 = expert • 0 = no knowledge • byj: relationship between resource y and its known skills and skill j calculated values range from 0 to 1 • 1 = strong relationship; resource y is an expert in the skill or a highly related skill • 0 = no knowledge in the skill or in a related skill • Fyt: fit of resource y to task t. Calculated values range from 0 to 1 • 1 = strong fit • 0 = resource is a bad fit for the task

49. BFR – Step 1:Task Required Skills Table

50. BFR – Step 2: Skill Relationships Table