Design of a Product-focused Customer-oriented Process

Size: px
Start display at page:

Download "Design of a Product-focused Customer-oriented Process"

Transcription

1 Design of a Product-focused Customer-oriented Process John Elliott Abstract In an increasingly dynamic world where both needs and technologies are changing rapidly, there is a requirement for whole-life Customer-oriented Processes (CoPs) for software systems and software development. In the pursuit of delivering 'fit for purpose' systems, the design of a CoP requires an holistic approach to understanding, engineering, managing and evolving the system and software needs and requirements. This paper summarises the CoP concepts and requirements, describes some evaluation results and proposes the way ahead. 1. Introduction A key goal for system developers is to deliver effective 'fit for purpose' product systems, within agreed project constraints, that satisfy real needs and thus provide tangible business advantage to customers. If successful, the delivery of a 'fit' system will largely result in a satisfied customer who will have received at least what was expected in terms of functionality and overall product quality, relevant to the business operational needs. Delivering fit products is a major part of achieving customer satisfaction. However, the degree of satisfaction will largely depend on the customer's perception (based on objective and subjective evidence) about the product, the development process, the project team, any demonstration and subsequent trials or operational usage. Unfortunately, too many customers of computer-based systems do not feel adequately satisfied for a number of reasons. They may receive a product that either does not fulfil needs or requirements, or they may not have sufficient confidence in the software product quality. Dissatisfied customers suffer from a lower than planned return on their software investment and also they can significantly affect any developer's business. This can result in a diminished reputation and loss of market share missing out on potential referrals or repeat business. Naturally we need to avoid such situations. This paper looks at the customer issues for software-based systems development. What factors affect customer satisfaction? How can the customer proactively acquire a 'fit for purpose' system and gain full product confidence? What does the developer need to do to ensure their customers are fully satisfied? These understandings are captured in a 'customer reference model'. This model underpins the design of a customer-oriented lifecycle process (CoP) that will extend the role of customers within system evolution activities. Following an analysis of customer issues and related models, the paper derives the requirements for such a CoP. Different lifecycle models are evaluated and illustrated against the CoP requirements. Finally, the paper concludes with the issues to be addressed to further develop and utilise a suitable and customisable CoP for system and software development. This paper is a further development of successful internal process improvement studies that also involved an European-funded Process Improvement Experiment, see [1,2] for further details, and see [3,4,5] for related dissemination activities. 2. Understanding Customer Satisfaction Perspectives 2.1. Customer Perceptions 383

2 As indicated, customers want a 'fit' product to meet intended needs. A 'fit' product is one that executes its intended functions as expected when required, and also possesses a suitable quality profile addressing non-functional attributes, e.g. reliability, maintainability, portability, usability, etc. The ultimate goal is to provide a high level of perceived, and actual, trust, in 'what the product can do' (function and performance) and 'how well it does it' (confidence in quality). The perception of performance and confidence depends on 'hard' and 'soft' information as attained through the execution of a software development lifecycle. Hard information will include plans and progress reports, requirements and designs, reviews and traceability analyses, quality audits and tests and demonstrations. Soft information will include the organisation and culture, the staff competence, and the control and execution of planned processes. There are four related 'process' influences on perceived customer satisfaction: the lifecycle paradigm (process model); the communication mechanisms (notation of representations, models, workshops); the team working arrangements (team or process roles); and the contracting style (formal agreements and expectations). All these 'process' influences directly affect the customer's visibility of hard and soft information and thus directly affect satisfaction. These influences are briefly described. Lifecycle paradigms. In fact, traditional lifecycle (e.g. V-model, waterfall variants) paradigms are probably the root cause of 'dissatisfaction' experiences. These lifecycles emphasise the developer's activities and assume that the customer's involvement in the project is minimised. The underlying process model often make a series of simplified assumptions about process interaction, including information transfer and transformation. In lifecycle model extensions, the activities of quality assurance and project provide further control activities in support of the development lifecycle. However, in all lifecycle models, customer activities are usually external entities. This leaves customers to set the requirements, to superficially monitor progress and to accept the delivered products; basically the customer provides selective inputs or receives expected outputs. This means that the lifecycles do not capture the richness of customer-development interaction to achieve common understandings, nor do they really account properly for the dynamics and the propensity for changing needs and requirements. Such changes are a result of various learning and feedback cycles. For example, there may be unexpected business environment pressures that force a change in business strategy and associated information needs. More common are changes in the software requirements that arise through an improved understanding (and user realisation) of how the software system will benefit, and fit into, the business operations. Communication mechanisms. These are the means of facilitating communication and common understanding. This will include controlled and structured workshops supported by agreed software representations that may be textual, graphical, model based formalisms and software prototypes. The use of suitably abstract common business and development concepts are critical to ensuring common understandings are achieved. All communication should be understandable to customers. It is often difficult to communication about software owing to its abstract 'problem solving' or behavioural nature. Ideally, customers need to think in more concrete terms (as the software is realised) and developers need to think in more abstract terms (in business and operational terms). The use of the wrong language/concepts for discussing business or software aspects is the most common cause of project problems. Team-working. The execution of the processes in the lifecycle need to be executed by defined roles, teams or organisations. In most project cultures, the customer and supplier spend very little effort engaged in joint activity to jointly own its results, e.g. a requirements or risk plan document. This means that customers state their requirements to be studied by 384

3 developers for clarification until understanding is (or believed to have been) attained. The problem is that communication gaps may appear by customers working in this largely 'review only' manner. These observations about current 'developer-oriented' lifecycles arise as separate customer activities and their interfaces with developer activities are not properly defined. Contracts. The communication situation is made worse as a typical software development contract tends to be adversarial; developers provide what customers said they wanted, and they argue later. The problem is the rigidity of the arrangements and when deviations occur, as they often do, a new formal arrangement is necessary to resolve or change the contract. Most changes in the need or requirements arise too late as they cannot be realised too early owing to the problems of achieving understanding that is initially based on abstract descriptions. These early descriptions may not accurately represent how the software will actually affect its business system context. In summary, the overall impact of the lifecycle, communication methods, team-working and contractual aspects constitute the root causes of many project failures; such project failures are really process failures. Joint 'customer-developer' activities and support communication methods tend to be largely unspecified in lifecycles. This may result in disastrous consequences, e.g. wrong system, expensive re-works, poor investment, stopped programmes, loss of competitiveness, etc. Overall, it is no wonder that software projects have failed too often when the role of the customer is given secondary importance. One argument is that as customers do not understand software technology (although software professionals do not understand business!), they do not need to be deeply involved in the development activities until the product is ready for inspection. Having analysed the factors that cause software project failures, viewed from a customer satisfaction perspective, the issue is what can be done proactively to avoid such failures. There appears to be three key questions all leading to lifecycle process remedies:?? What do we mean by achieving customer satisfaction??? What goals need to be satisfied to achieve customer satisfaction??? When will we know when we have, or likely to have, achieved customer satisfaction?' The next sub-section develops a customer reference model to provide an understanding prior to developing the requirements in terms of measurable goals for a customer-oriented process Customer Reference Model The purpose of a customer reference model is to provide the essential understanding from which customer satisfaction can be assessed. The model expresses the customer satisfaction problem domain using four key related components, each representing a measurable dimension. As shown in Figure 1, the model components are:?? Business need (i.e. need for new business strategy and change).?? System requirements (i.e. the user/system product definition including quality levels and process criteria and constraints).?? Confidence in the quality approach (i.e. in the process capability and people competence).?? Product quality (i.e. demonstration about quality and fitness). This model represents an 'idealistic' situation if all its components maximise their contribution to customer satisfaction. For example, customer satisfaction is achieved when the product matches the need that is also accurately transformed and expressed in any requirement materials. The requirements also influence the processes to be used and any 385

4 expectations about the organisation and competence of the teams involved. The process execution will provide both 'hard' and 'soft' information about the development activities, notwithstanding the major demonstrations or evidence about the product's ability to meet the stated need and deliver trustworthy product quality. It should be apparent that the model components can have measurable attributes based on scores and /or factual information about the process outputs; e.g. for need: % of priority requirements satisfied, % of need statements not having a traceable requirement, expected and actual return of investment when need statements satisfied, etc. Any measurement scheme derived from this model will provide both component and composite customer satisfaction indicators. Adaptive Understanding Business Need Reflected as System Requirement Business criteria for success Technical criteria for success Contributes to Customer satisfaction Influencing approach to Depends on Depends on Product Quality Supports Confidence in Quality Assurance Team-working Figure 1 - Customer Reference Model This model is designed to capture the concepts involved in customer satisfaction. However, it may be developed into a more detailed behavioural model, to be expressed using various chosen process, object and information modelling notations. Such a model will refine the processes that address need, requirements, confidence and product quality. The development of further modelling and measurement schemes is an ongoing activity. 3. Customer-oriented Process Design 3.1. Deriving Customer-oriented Process requirements The customer reference model provides an understanding about customer satisfaction by identifying four measurable dimensions. The design of a CoP needs to achieve a set of goals to be realised and measured using the identified dimensions of need, requirements, confidence in process/people, and product quality. Some inter-related goals have been defined: 386

5 ?? Understanding - that both customers and developers throughout an evolutionary-oriented development lifecycle fully and unambiguously understand the business need and requirements.?? Team working - that customers and developers work towards the same project objectives within a trusting and respectful partnership to be based on effective communication, decision making and action.?? Assurance - that the resulting product meets the required level of quality and is fit for its purpose and supported by lifecycle generated information.?? Adaptability - that the inevitable changes in the customer's perception or situation about the business need and the system requirements are adequately accommodated. These goals are added to the reference model in Figure 1 above. This highlights that assurance is combining evidence about the definition and execution of the process, the people (, and technical - engineering and quality) competence and the product quality (based on verification, validation and testing, and demonstration evidence). The inter-relationships between these goals may lead to various process design trade-offs. This is highlighted in Figure 2. For example, 'understanding' is central to creating 'fit' products and it depends on team-working and associated communication effectiveness, although it contributes to providing assurance. Also, the 'adaptive' goal is necessary to ensure current and priority needs are met, enhancing assurance, but this depends on the successful understanding of business changes. Assurance Through visibility Team-working Delivers fit products Through communication Through change Understanding Understand dynamics Adaptability Figure 2- Relationships between Customer Oriented Process Goals These CoP goals set the framework for defining the requirements as process criteria to be used when creating or evaluating different lifecycle processes to achieve customer-orientation. Furthermore, any deviation from the process criteria will serve to highlight any needs for change (i.e. to improve) and further support (i.e. techniques and tools for implementation) of lifecycle processes. The following table sets out the goals, criteria and requirements. The 'goal-criteria' style of presenting requirements provides an opportunity to further develop a measurement scheme. This measurement scheme may be based on supporting arguments about customer satisfaction that combine:?? Experience (e.g. translated into a score based on the degree to which each cop requirement satisfied)?? Qualitative results (e.g. Class of effectiveness or difficulty - high, medium, low within through-life understanding)?? Quantitative information (e.g. number or % of paths tested within assurance). The development of measurement schemes is outside the scope of this paper. 387

6 Goal Criteria Requirements Through life Understanding & Evolution Evolution & increment Need capture Req t capture Usability Visibility?? Through-life treatment of system requirements and business need; this will focus attention on the ultimate project goals and success criteria?? Need to embrace the whole system evolution lifecycle; this will ensure that systems are not viewed as totally new but rather as add-ons or modifications to existing, albeit larger, systems.?? Need to ensure that customers get operational systems as a series of increments to meet shorter-term priority needs; this will enable customers to get useful employable systems as a series of incremental deliveries formed within an well-founded overarching business system architecture.?? Need to understand the business needs for operational system changes.?? Need to elicit and express the requirements for the new operational systems.?? Need to be able to define the environment activities that will interact with the new operational software systems.?? Need to be able to test thorough analysis, demonstration or simulation that the software interfaces as expected, or as desirable, with the operational activities?? Enable executable system prototypes to be visible and allowing user 'play back'; this enables the customer team to see the evolving product in concrete terms and respond accordingly. Adaptability Need change Requirement change?? Need to be flexible to changing customer needs and perspectives; this will encourage effective contracting and working arrangements to be in place that are based on the premise that such change is inevitable and technical agreements will need to change.?? Need to manage the customer needs and their satisfaction through a flexible yet controllable approach to system planning and its execution; this will focus both parties on the theme of customer satisfaction and project success by on-going needs understanding.?? Need to manage the customer requirements, derived from the business needs, and their satisfaction through a flexible yet controllable approach to system planning and its execution; this will focus both parties on the theme of customer satisfaction and project success by on-going requirements understanding.?? Need to be able to roll the current system solution both forwards and backwards; this assists the speed at which changes (using new or old perspectives) can be played back.?? Must be fast to react to changing customer perspectives about system requirements; this assists customers to quickly see the impact of their desired changes. Team-working & communication Partnership & contracts Info interfaces Interactions Universality?? Need for customer-supplier teams to work in partnership; this will enable both parties with separate overall business aims to share a more focused and explicit common project goal within a trusted contractual and working relationship that involves more risk and information sharing, and joint decision making.?? Needs effective communication/interfacing between customer and supplier teams; this enables a common and shared understanding about the business need, system requirements, and the development processes and products.?? Need customers and suppliers to be regularly interactive about key business and development changes affecting the partnership; this enables an on-going approach to holism, learning and adaptability throughout system evolution.?? Need frequent customer feedback to design concepts and system increments prior to final acceptance and in-service use; this will ensure that customers declare timely change based on business use perspectives.?? All appropriate processes, methods and tools need to be universally understandable and accessible to all those involved in the customer and developer teams. Assurance Product effectiveness Process People Project?? Need to define acceptable fitness in terms of functional and non-functional attributes. Need to enable the risk and quality levels to be defined and agreed to apply to the functional and non-functional attributes; this leads to different needs for process, project and people.?? Need to provide effective demonstration and control mechanisms to decide about system fitness; this will enable customers and suppliers to understand any arguments based on evidence about risks and fitness prior to operational use.?? Need to define process criteria for checking defined process are appropriate and being employed effectively, to be used in process audits and assessments.?? Need to define staff competencies in terms of qualifications and experience relevant for their roles.?? Need to define processes for planning, monitoring and controlling the development; this focuses on what resources and activities are needed to meet the project objectives. 388

7 Table 1 - Customer-oriented Process Goal, Criteria and Requirements 3.2. Implementing CoPs A CoP is a lifecycle framework to be populated with a series of techniques and tools (e.g. facilitation, requirements/modelling language and tool support) to be tailored for a given project. Tailoring means selecting the process, techniques and tools that are appropriate for the project requirements. This will encompass technical engineering, project and quality assurance activities. The principles for detailing a CoP implementation are as follows:?? Customers and developers to be committed to joint team working - for tasks, decisions, information and risk sharing throughout the development programme from concept through to operation and maintenance. This impacts on organisational cultures and contracting practice.?? A product focus is required throughout the project. This will require an on-going business focus but it will also required different product criteria for assessing product quality throughout the lifecycle. More demonstration and on-going assessment is required, in addition to regulated process assessment.?? Frequent delivery of intermediate and final - operational - increments are requited to maximise visible and to elicit customer feedback.?? Project planning needs to be at a high level initially to be refined through the addition of detailed incremental sub-plans to reflect progress and changing circumstances.?? Initial needs and requirements may be a high level to start initial modelling or prototyping to be refined through enhanced customer review, feedback and understanding.?? Well-defined cycles for coping with customer feedback and the dynamics of change are needed.?? Understandable modelling representations of needs, requirements and designs are needed - using commonly understood business and technical concepts.?? A clear role-based approach to joint team-working must be defined with identified roles and responsibilities.?? Competent, trained and experienced personnel on both customer and supplier sides are required. This is critical for CoPs where enhanced customer interaction is involved.?? Effective and efficient tool-sets for prototyping, animation and play-back activities are important. This is an example where trained and competent engineers are required.?? Continuous attention to product quality control and configuration is essential.?? The use of structured and controlled workshops is necessary to facilitate effective communication. 4. Lifecycle Process Evaluation In order to illustrate the CoP ideas, various lifecycle models are evaluated for their customer-friendliness using the customer-oriented process criteria defined. Three lifecycle models are chosen to represent extremes in terms of their flexibility and control approaches:?? Waterfall/V-models without feedback apart from verification between stages, see [6]?? Prototyping and evolution models with controlled feedback. Many iterative cycles are allowed as requirements evolve through improved understanding, see [6].?? Rapid application development (RAD) based models allowing unspecified feedback cycles. This is illustrated using Dynamic System Development Method (DSDM), see [7,8]. 389

8 These models are shown in Figure 3 below. Concept Requirements Specification Architectural design Module design Operation Acceptance test System test Integration test Module test Software concept Preliminary requirements analysis Design of architecture and system core Incorporate feedback Create a version Deliver a version Deliver final version Module code Elicit customer feedback 3 a) Waterfall/V-Model 3 b) Evolutionary/Prototyping Model Figure 3 a) Waterfall/V-Model, b) Evolutionary/Prototyping Model and c) Rapid Application Development/Dynamic Systems Development Method The result of assessing each lifecycle model against the CoP criteria is shown graphically in Figures 4. One main conclusion is that the evolutionary/rad approaches exhibit greater understanding but some variation arises on adaptability, team-working and assurance. The RAD/DSDM model offers more promise in most criteria. It is particularly strong in the areas of team working and adaptability, but questionable in the area of assurance. Whilst being very product focussed, RAD/DSDM's quality control approach requires new strategies to enhance overall confidence and satisfaction. In RAD/DSDM, it should be noted that product effectiveness is high as testing and trials are continuously undertaken involving the customer, even though there is a question over the resulting inherent (internal) product quality. Of Phase 1 Feasibility Phase 2 Business Study Phase 3 FUNCTIONAL MODEL DESIGN Phase 5 IMPLEMENTATION Transfer Prototypes Phase 4 DESIGN AND BUILD ITERATION 3 c) RAD/DSDM Model course, these product quality issues are likely to remain dormant and invisible to external demonstrations to the customer. On the whole, most lifecycles do not address the customer need very well. RAD/DSDM attempts to understand the need in a business study - but it is intended to be quick and not based on any form of business model analysis. In general, all cycles assume that the 390

9 customers perform analyses to determine their needs prior to triggering the requirements for a software-based system, to be subsequently integrated into the future business operations. Requirements and change activities have received considerable attention in terms of engineering models and processes, and thus opportunities for effective requirements is generally good, providing adaptable processes are in place. It is noted that less CoP Goals attention is paid to freezing ultra-detailed requirements in the evolutionary lifecycles, particularly DSDM, where higher-level changeable requirements are initially postulated. These Criteria CoP Compliance 1(low) (high) Through Life Understanding Key: V-Model Evolutionary RAD/DSDM Evolutionary & incremental Need capture Req t capture Usability Adaptability Visibility Need change mgt Assurance Req t change mgt Product effectiveness Process mgt People mgt Team working Project mgt Partnership & contracts Info interfaces Interactions Universality requirements evolve with the system development. Figure 4 - Evaluating life cycle models using the CoP requirements In all lifecycles, the emphasis on assurance is a key aspect - when more feedback cycles are involved, there tends to be more on-going product checks to maintenance product quality and assurance. 391

10 What has been ignored to date is how effective are these lifecycle process when measured using different customer satisfaction indicators, but within typical cost and time constraints. Possible indicators are given in Figure 5, for the three lifecycle-types studied. The potential indicators include a normalised customer satisfaction measure (a composite of customer reference model indicators of need, requirements, confidence and product quality), a satisfaction efficiency ratio (project size dependent) and a satisfaction speed rate (project duration dependent). The indicators shown are by conjecture - no experiments have been involved. They show the scope for comparing and estimating customer effectiveness from lifecycle process definitions, using high to low granularity. high Key: V-Model Evolutionary RAD/DSDM medium low Customer satisfaction Satisfaction efficiency Satisfaction speed Figure 5 - Indicative customer measures for different models 5. Way Ahead for Customer-oriented Processes The analysis in this paper highlights that a customer perspective on lifecycle processes can be illustrative and highlight current weaknesses in addressing customer issues. This section highlights the areas for usage and advancement of customer-orientation within process design. The main proposal in the paper is to develop a CoP lifecycle process model that optimises the likelihood of achieving multi-faceted customer satisfaction. This optimisation will depend on the degree to which customer satisfaction can be understood, measured and controlled. Hence it is important to develop measures of process effectiveness to characterise customer orientation. The more measurement opportunities then the greater the degree of process finetuning and project successes. Interesting approaches including those providing statistical process control are emerging, see [9], project success measures, see [10], and sound measurement concepts are surveyed in [11]. Another proposal is to enhance existing lifecycles - often ingrained into organisations - to provide more customer and product focus by using the CoP goals and criteria. Areas such as systems engineering (via INCOSE, ISO) and systems procurement (UK MoD) are developing current modern process practices and these are starting to reflect the customer orientation. This is being achieved through developing interacting processes that capture what the customer's do (acquisition and operations) and what supplier's do (develop and maintain). These developments, discussed in [12], indicates the use of holistic and system 392

11 thinking in designing process and product systems. Systems engineering progress is a useful source of support for improving the software lifecycle models to be customer-oriented. The CoP theme has strong business connections and could be a central component to influence software process improvement decisions in order to deliver benefits to the developer's business as well as to the customer businesses through projects. This is an important area for future research. In addition, as these CoP-based processes are to be performed by humans, there is a need to include human factor and communication considerations within future studies of process system design. The refinement of the 'best features' from RAD/DSDM and the other lifecycles may be used to generate a CoP benchmark. This could be the basis of a useful demonstrator of processes that are feasible and practical, yet theoretically founded by the reference model. In such an exercise, the issues of quality, project, organisational cultures, and process integration (to ISO based procedures) need to be considered. Finally, the use of measures and models to assess the benefits of software process improvement changes towards a CoP approach to customers and developers would be a major break-through. This paper sets the scene for such worthwhile activity. No discussion of processes would be complete without reference to the world-wide initiatives on process maturity and assessment reference models (acting as consensus benchmarks of best practice), e.g. CMM, SPICE, BOOTSTRAP, all are discussed in [13]. These models are largely limited to the developer's process areas and their association with maturity levels attempt to indicate the degree to which an organisation, or project, process is established or sophisticated. The higher the level of maturity the more measurement and feedback cycles are used within operating process improvement systems. However, a simplified conclusion is that these process assessment models do not explicitly support system evolution and customer orientations. Hence the future development of these assessment models could be extended to be more customer oriented. Rather than ask ' is the process compliant with best development practice?' we may ask 'is the process suitability focussed on delivering fit products and achieving customer satisfaction?'. The role of the CoP theme should be addressed within the development of the many process standards. It is close to those activities addressing usability, product quality and evaluation, and process assessment. Ideally, once the customer reference models and associated measurement systems are more advanced, experimental studies with real projects will enable the lifecycle model effectiveness with respect to customer satisfaction to be studied. This will enable the CoP requirements to be refined and further validated. For the reader's information, further development and validation of the customer reference models is in progress. Also the definition of associated measurements scheme that are linked to the reference model is being considered. These developments will support the more concrete issues when developing, enhancing or assessing lifecycle processes to be customer oriented. On the whole, further research activity is required to make the focus on customer satisfaction, of importance, one that is realistic within a range of development situations. 6. Summary This paper has described the results of an analysis of customer satisfaction perspectives and the typical causes of process, and thus development project, failures. This led to the development of a customer reference model. This model was used to develop the goals and criteria to act as the requirements for developing, or evaluating designated, customer-oriented lifecycle processes (CoPs). The model-based foundation for these processes provides an 393

12 opportunity for devising a scheme to measure the effectiveness of lifecycle processes in terms of customer satisfaction and related attributes. Some high level guidance for implementing CoPs is offered in order to ensure project success. An evaluation of different lifecycle models (i.e. waterfall and V-based, prototyping and evolutionary-based, RAD and DSDM-based) was undertaken and their compliance with the CoP requirements was illustrated. The conclusion was that evolutionary and RAD style lifecycles form the basis for the further definition of CoPs that should achieve high levels customer satisfaction through delivering 'fit' products within typical project cost and time constraints. 'Fit' products are those that meet real business needs with a high, or acceptable, level of confidence. Customer satisfaction is a result of the CoP emphasis on understanding, team-working, assurance and adaptability. Finally the potential for defining customer friendly and evolutionary development lifecycles was discussed highlighting the way ahead and the impact of the approach proposed. Although much research is needed, the evidence from our studies [1,2] is that a customer focus yields immediate benefits. 7. Acknowledgements and Disclaimers The author would like to acknowledge the internal Defence Evaluation and Research Agency funding on the general concept studies and the external European Commission funding of a Process Improvement Experiment, (REJOICE, Project 23893). The views expressed in this paper are entirely those of the author and do not represent the views, policy or understanding of any other person or official body. Any feedback, expressions of interest, or just further details can be requested from the author at the Defence Evaluation and Research Agency (DERA Malvern), Systems and Software Engineering Centre, Tel: , jjelliott@dera.gov.uk. 8. References [1] Raynor-Smith, P. M., Elliott J. J., REJOICE Final Report, Version 1.0, May 1999 [2] ESSI VASIE website: [3] Elliott J, "Achieving Customer Satisfaction through Requirements Understanding", In: Project Control for Software Quality, Proceedings of ESCOM-SCOPE, April, Shaker, 1999 [4] Elliott J, Raynor-Smith P, "Achieving Customer Satisfaction through Requirements Understanding", In: Proceedings of Quality Week Europe, 2-5 Nov [5] Elliott J, Raynor-Smith P, "Achieving Customer Satisfaction through Requirements Understanding", In: Software Process Technology, EWSPT 2000, Lecture Notes in Computer Science, Springer, 2000 [6] McConnell, S., "Rapid Development", Microsoft Press, 1996 [7] DSDM Consortium, "DSDM Manual", 1996 [8] Stapleton J., "Dynamic Systems Development Method", Addison-Wesley, 1997 [9] Florac W, Carleton A, "Measuring the Software Process", Addison-Wesley, 1999 [10] Garrity E, Saunders G L, "Information Systems Success Measurement", IDEA Group 1998 [11] Fenton N, Pfleeger S L, "Software Metrics, Second Edition", Thompson, 1997 [12]Stevens R, Arnold S, Jackson, K, Brook P, "Systems Engineering - Coping with Complexity", Prentice Hall Europe, 1999 [13] Zahran S, "Software Process Improvement", Addison-Wesley,

Software Processes 1

Software Processes 1 Software Processes 1 Topics covered Software process models Process activities Coping with change 2 The software process A structured set of activities required to develop a software system. Many different

More information

1 Management Responsibility 1 Management Responsibility 1.1 General 1.1 General

1 Management Responsibility 1 Management Responsibility 1.1 General 1.1 General 1 Management Responsibility 1 Management Responsibility 1.1 General 1.1 General The organization s management with executive The commitment and involvement of the responsibility shall define, document

More information

Lecture 1. In practice, most large systems are developed using a. A software process model is an abstract representation

Lecture 1. In practice, most large systems are developed using a. A software process model is an abstract representation Chapter 2 Software Processes Lecture 1 Software process descriptions When we describe and discuss processes, we usually talk about the activities in these processes such as specifying a data model, designing

More information

The software process

The software process Software Processes The software process A structured set of activities required to develop a software system Specification; Design; Validation; Evolution. A software process model is an abstract representation

More information

Lectures 2 & 3. Software Processes. Software Engineering, COMP201 Slide 1

Lectures 2 & 3. Software Processes. Software Engineering, COMP201 Slide 1 Lectures 2 & 3 Software Processes Software Engineering, COMP201 Slide 1 What is a Process? When we provide a service or create a product we always follow a sequence of steps to accomplish a set of tasks

More information

II. Software Life Cycle. Laurea Triennale in Informatica Corso di Ingegneria del Software I A.A. 2006/2007 Andrea Polini

II. Software Life Cycle. Laurea Triennale in Informatica Corso di Ingegneria del Software I A.A. 2006/2007 Andrea Polini II. Software Life Cycle Laurea Triennale in Informatica Corso di Objectives To introduce software process models To describe three generic process models and when they may be used To describe outline process

More information

Objectives. The software process. Topics covered. Waterfall model. Generic software process models. Software Processes

Objectives. The software process. Topics covered. Waterfall model. Generic software process models. Software Processes Objectives Software Processes To introduce software process models To describe three generic process models and when they may be used To describe outline process models for requirements engineering, software

More information

Software Processes. Objectives. Topics covered. The software process. Waterfall model. Generic software process models

Software Processes. Objectives. Topics covered. The software process. Waterfall model. Generic software process models Objectives Software Processes To introduce software process models To describe three generic process models and when they may be used To describe outline process models for requirements engineering, software

More information

Software Processes. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1

Software Processes. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1 Objectives To introduce software process models To describe three generic process models and when they may be

More information

Topics covered. Software process models Process iteration Process activities The Rational Unified Process Computer-aided software engineering

Topics covered. Software process models Process iteration Process activities The Rational Unified Process Computer-aided software engineering Software Processes Objectives To introduce software process models To describe three generic process models and when they may be used To describe outline process models for requirements engineering, software

More information

Based on Software Engineering, by Ian Sommerville Coherent sets of activities for specifying, designing, implementing and testing software systems

Based on Software Engineering, by Ian Sommerville Coherent sets of activities for specifying, designing, implementing and testing software systems Software Processes Based on Software Engineering, by Ian Sommerville Coherent sets of activities for specifying, designing, implementing and testing software systems Slide 1 Objectives To introduce software

More information

Lecture 2: Software Quality Factors, Models and Standards. Software Quality Assurance (INSE 6260/4-UU) Winter 2016

Lecture 2: Software Quality Factors, Models and Standards. Software Quality Assurance (INSE 6260/4-UU) Winter 2016 Lecture 2: Software Quality Factors, Models and Standards Software Quality Assurance (INSE 6260/4-UU) Winter 2016 INSE 6260/4-UU Software Quality Assurance Software Quality Quality Assurance Factors and

More information

SWE 211 Software Processes

SWE 211 Software Processes SWE 211 Software Processes These slides are designed and adapted from slides provided by Software Engineering 9 /e Addison Wesley 2011 by Ian Sommerville 1 Outlines Software process models Process activities

More information

ERROR! BOOKMARK NOT DEFINED.

ERROR! BOOKMARK NOT DEFINED. TABLE OF CONTENTS LEAD AND LAG INDICATORS... ERROR! BOOKMARK NOT DEFINED. Examples of lead and lag indicators... Error! Bookmark not defined. Lead and Lag Indicators 1 GLOSSARY OF TERMS INTRODUCTION Many

More information

Software Engineering

Software Engineering Software Engineering Part I. Aspects and Models of Software Development Process Gunadarma University 1 Software Engineering Outline 1 Introduction 2 Aspects of Software Engineering Software Engineering

More information

CMSC 435: Software Engineering Section Back to Software. Important: Team Work. More Resources

CMSC 435: Software Engineering Section Back to Software. Important: Team Work. More Resources CMSC 435: Software Engineering Section 0101! Atif M. Memon (atif@cs.umd.edu)! 4115 A.V.Williams building! Phone: 301-405-3071! Office hours!.tu.th. (10:45am-12:00pm)! Don t wait, don t hesitate, do communicate!!!

More information

MINOTAUR - A VICTIM OF ITS OWN SUCCESS? ACCOMMODATING EVOLVING AND CONFLICTING SOFTWARE REQUIREMENTS

MINOTAUR - A VICTIM OF ITS OWN SUCCESS? ACCOMMODATING EVOLVING AND CONFLICTING SOFTWARE REQUIREMENTS MINOTAUR - A VICTIM OF ITS OWN SUCCESS? ACCOMMODATING EVOLVING AND CONFLICTING SOFTWARE REQUIREMENTS Graeme Rainbird and Adam Pallant RM Consulting, The Post Office Technology Centre, Wheatstone Road,

More information

Software Reliability

Software Reliability Software Reliability Measuring Software Reliability D L BIRD 2003 Abstract This paper sets out a technique for measuring software reliability. It introduces a new style of metric that establishes software

More information

Digital Industries Apprenticeship: Occupational Brief. Software Development Technician. September 2016

Digital Industries Apprenticeship: Occupational Brief. Software Development Technician. September 2016 Digital Industries Apprenticeship: Occupational Brief Software Development Technician September 2016 1 Digital Industries Apprenticeships: Occupational Brief Level 3 Software Development Technician Apprenticeship

More information

Dr. Aldo Dagnino ABB, Inc. US Corporate Research Center October 21 st, Requirements Engineering

Dr. Aldo Dagnino ABB, Inc. US Corporate Research Center October 21 st, Requirements Engineering Dr. Aldo Dagnino ABB, Inc. US Corporate Research Center October 21 st, 2003 Requirements Engineering Class Objectives Students will be able to define the two process areas associated with the Requirements

More information

Digital Industries Apprenticeship: Occupational Brief. Software Development Technician. September 2016

Digital Industries Apprenticeship: Occupational Brief. Software Development Technician. September 2016 Digital Industries Apprenticeship: Occupational Brief Software Development Technician September 2016 1 Digital Industries Apprenticeships: Occupational Brief Level 3 Software Development Technician Apprenticeship

More information

Acquiring Digital Services for Defence using the Government Service Design Manual

Acquiring Digital Services for Defence using the Government Service Design Manual Acquiring Digital Services for Defence using the Government Service Design Manual How can the Government Service Design Manual be aligned to Defence Investment Approval requirements? What Benefits does

More information

Enterprise Asset Management. Enterprise Asset Management 1

Enterprise Asset Management. Enterprise Asset Management 1 Enterprise Asset Management 1 Introduction Managing assets effectively is critical to the success of organisations that depend on complex physical assets to deliver services. Increasingly, operators and

More information

This chapter illustrates the evolutionary differences between

This chapter illustrates the evolutionary differences between CHAPTER 6 Contents An integrated approach Two representations CMMI process area contents Process area upgrades and additions Project management concepts process areas Project Monitoring and Control Engineering

More information

Pertemuan 2. Software Engineering: The Process

Pertemuan 2. Software Engineering: The Process Pertemuan 2 Software Engineering: The Process Collect Your Project Topic What is Software Engineering? Software engineering is the establishment and sound engineering principles in order to obtain economically

More information

BCS THE CHARTERED INSTITUTE FOR IT. BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 6 Professional Graduate Diploma in IT SOFTWARE ENGINEERING 2

BCS THE CHARTERED INSTITUTE FOR IT. BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 6 Professional Graduate Diploma in IT SOFTWARE ENGINEERING 2 BCS THE CHARTERED INSTITUTE FOR IT BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 6 Professional Graduate Diploma in IT SOFTWARE ENGINEERING 2 Friday 30 th September 2016 - Morning Answer any THREE questions

More information

CLASS/YEAR: II MCA SUB.CODE&NAME: MC7303, SOFTWARE ENGINEERING. 1. Define Software Engineering. Software Engineering: 2. What is a process Framework? Process Framework: UNIT-I 2MARKS QUESTIONS AND ANSWERS

More information

Rational Software White Paper TP 174

Rational Software White Paper TP 174 Reaching CMM Levels 2 and 3 with the Rational Unified Process Rational Software White Paper TP 174 Table of Contents Abstract... 1 Introduction... 1 Level 2, Repeatable... 2 Requirements Management...

More information

Requirements Analysis and Design Definition. Chapter Study Group Learning Materials

Requirements Analysis and Design Definition. Chapter Study Group Learning Materials Requirements Analysis and Design Definition Chapter Study Group Learning Materials 2015, International Institute of Business Analysis (IIBA ). Permission is granted to IIBA Chapters to use and modify this

More information

ISO 9001: Moving from requirement to

ISO 9001: Moving from requirement to ISO 9001: Moving from requirement to reality J. Hemington of ABSTRACT Quality Systems work. Given the right design, implementation and support a Quality System can make an important contribution to improving

More information

Introduction to Software Project Management. CITS3220 Software Requirements & Project Management

Introduction to Software Project Management. CITS3220 Software Requirements & Project Management Introduction to Software Project Management CITS3220 Software Requirements & Project Management "A project gets a year late one day at a time." "Anything that can be changed will be changed until there

More information

Agile Projects 7. Agile Project Management 21

Agile Projects 7. Agile Project Management 21 Contents Contents 1 2 3 4 Agile Projects 7 Introduction 8 About the Book 9 The Problems 10 The Agile Manifesto 12 Agile Approach 14 The Benefits 16 Project Components 18 Summary 20 Agile Project Management

More information

T E A L C O N S U L T I N G L T D I S O A G U I D E

T E A L C O N S U L T I N G L T D I S O A G U I D E T E A L C O N S U L T I N G L T D I S O 4 4 0 0 1 A G U I D E W H A T I S I S O 4 4 0 0 1? There is much talk about collaboration but for many the concept seems ad hoc and without a clear perspective as

More information

Chapter 3 Prescriptive Process Models

Chapter 3 Prescriptive Process Models Chapter 3 Prescriptive Process Models - Generic process framework (revisited) - Traditional process models - Specialized process models - The unified process Generic Process Framework Communication Involves

More information

Transactions on Information and Communications Technologies vol 11, 1995 WIT Press, ISSN

Transactions on Information and Communications Technologies vol 11, 1995 WIT Press,   ISSN A quality assessment method for application management R.M. Hather, E.L. Burd, C. Boldyreff Centre for Software Maintenance, University of Durham, Durham, DEI 3EL, UK, Email: ames@durham.ac.uk Abstract

More information

Internal self assessment

Internal self assessment Internal self assessment Understanding your internal capability for collaboration is a crucial part of developing the right platform for building effective relationships. About PSL PSL (Partnership Sourcing

More information

Software Engineering Part 2

Software Engineering Part 2 CS 0901341 Software Engineering Part 2 In this part, we look at 2.1 Software Process 2.2 Software Process Models 2.3 Tools and Techniques for Processing Modelling As we saw in the previous part, the concept

More information

Quality Assessments of Statistical Production Processes in Eurostat Pierre Ecochard and Małgorzata Szczęsna, Eurostat

Quality Assessments of Statistical Production Processes in Eurostat Pierre Ecochard and Małgorzata Szczęsna, Eurostat Quality Assessments of Statistical Production Processes in Eurostat Pierre Ecochard and Małgorzata Szczęsna, Eurostat Since 1994, Eurostat has developed its own approach for the measurement of the quality

More information

Capability Maturity Model for Software (SW-CMM )

Capability Maturity Model for Software (SW-CMM ) PHASE-IV: SYSTEMS IMPLEMENTATION Software Quality Assurance Application Development Installation and Support Software Quality Assurance Capability Maturity Model for Software (SW-CMM ) The Capability Maturity

More information

A cost capability maturity analysis of the US and European costing communities

A cost capability maturity analysis of the US and European costing communities A cost capability maturity analysis of the US and European costing communities by Mark Gilmour and Dale Shermon, QinetiQ mwgilmour@qinetiq.com dshermon@qinetiq.com Abstract - High quality cost estimating

More information

Project Managers Guide to Systems Engineering Measurement for Project Success

Project Managers Guide to Systems Engineering Measurement for Project Success Practical Software and Systems Measurement Project Managers Guide to Systems Engineering Measurement for Project Success June 16, 2017 Greg Niemann gregory.niemann@lmco.com Project Managers Guide to Systems

More information

4 The balanced scorecard

4 The balanced scorecard SUPPLEMENT TO THE APRIL 2009 EDITION Three topics that appeared in the 2007 syllabus have been removed from the revised syllabus examinable from November 2009. If you have the April 2009 edition of the

More information

How I Learned to Stop Worrying and Love Benchmarking Functional Verification!

How I Learned to Stop Worrying and Love Benchmarking Functional Verification! How I Learned to Stop Worrying and Love Benchmarking Functional Verification! Mike Bartley Test and Verification Solutions SETsquared Business Acceleration Centre University Gate East, Park Row Bristol

More information

FOUNDATIONAL CONCEPTS FOR MODEL DRIVEN SYSTEM DESIGN

FOUNDATIONAL CONCEPTS FOR MODEL DRIVEN SYSTEM DESIGN FOUNDATIONAL CONCEPTS FOR MODEL DRIVEN SYSTEM DESIGN Loyd Baker, Paul Clemente, Bob Cohen, Larry Permenter, Byron Purves, and Pete Salmon INCOSE Model Driven System Interest Group Abstract. This paper

More information

Software Engineering

Software Engineering Software Engineering (CS550) Software Development Process Jongmoon Baik Software Development Processes (Lifecycle Models) 2 What is a S/W Life Cycle? The series of stages in form and functional activity

More information

Software Engineering & Architecture

Software Engineering & Architecture Software Engineering & Architecture 10. SOFTWARE EVOLUTION Martin Kropp University of Applied Sciences Northwestern Switzerland Institute for Mobile and Distributed Systems References Based on the PowerPoint

More information

7. Project Management

7. Project Management Subject/Topic/Focus: 7. Project Management Management of Systems Engineering Processes Summary: Project management Systems engineering Maturity model and process improvement Literature: Ian Sommerville:

More information

Capability Maturity Model the most extensively used model in the software establishments

Capability Maturity Model the most extensively used model in the software establishments International Journal of Scientific and Research Publications, Volume 6, Issue 5, May 2016 710 Capability Maturity Model the most extensively used model in the software establishments Ajith Sundaram Assistant

More information

NATO STANDARD AQAP-2210

NATO STANDARD AQAP-2210 NATO STANDARD AQAP-2210 NATO SUPPLEMENTARY SOFTWARE QUALITY ASSURANCE REQUIREMENTS TO AQAP-2110 OR AQAP-2310 Edition A Version 2 September 2015 NORTH ATLANTIC TREATY ORGANIZATION ALLIED QUALITY ASSURANCE

More information

A RFBSE model for capturing engineers useful knowledge and experience during the design process

A RFBSE model for capturing engineers useful knowledge and experience during the design process A RFBSE model for capturing engineers useful knowledge and experience during the design process Hao Qin a, Hongwei Wang a*, Aylmer Johnson b a. School of Engineering, University of Portsmouth, Anglesea

More information

Software Process - Standards, Assessments and Improvement

Software Process - Standards, Assessments and Improvement Chapter 2 Software Process - Standards, Assessments and Improvement (1) Chapter Editor: Wolfgang Emmerich (WE) (2) Participants: AF, CM, JCD (3) Software engineering and software process improvement standards

More information

Software Development Methodologies

Software Development Methodologies Software Development Methodologies Lecturer: Raman Ramsin Lecture 1: Basics 1 Software Development Methodology (SDM) A framework for applying software engineering practices with the specific aim of providing

More information

Tassc:Estimator technical briefing

Tassc:Estimator technical briefing Tassc:Estimator technical briefing Gillian Adens Tassc Limited www.tassc-solutions.com First Published: November 2002 Last Updated: April 2004 Tassc:Estimator arrives ready loaded with metric data to assist

More information

CHAPTER 52 SOFTWARE RELIABILITY EVALUATION CONTENTS

CHAPTER 52 SOFTWARE RELIABILITY EVALUATION CONTENTS Applied R&M Manual for Defence Systems Part C R&M Related Techniques CHAPTER 52 SOFTWARE RELIABILITY EVALUATION CONTENTS Page 1 Introduction 2 2 Evidence from Testing 2 3 Use of Field Data 3 4 Evidence

More information

Evolutionary Differences Between CMM for Software and the CMMI

Evolutionary Differences Between CMM for Software and the CMMI Evolutionary Differences Between CMM for Software and the CMMI Welcome WelKom Huan Yín Bienvenue Bienvenido Wilkommen????S???S??? Bienvenuto Tervetuloa Välkommen Witamy - 2 Adapting an An Integrated Approach

More information

Level 5 NVQ Diploma in Management and Leadership Complete

Level 5 NVQ Diploma in Management and Leadership Complete Learner Achievement Portfolio Level 5 NVQ Diploma in Management and Leadership Complete Qualification Accreditation Number: 601/3550/5 Version AIQ004461 Active IQ wishes to emphasise that whilst every

More information

CMMI-DEV V1.3 CMMI for Development Version 1.3 Quick Reference Guide

CMMI-DEV V1.3 CMMI for Development Version 1.3 Quick Reference Guide processlabs CMMI-DEV V1.3 CMMI for Development Version 1.3 Quick Reference Guide CMMI-DEV V1.3 Process Areas Alphabetically by Process Area Acronym processlabs CAR - Causal Analysis and Resolution...

More information

UoD IT Job Description

UoD IT Job Description UoD IT Job Description Role: Service Delivery Manager (People HERA Grade: 8 Management Systems) Responsible to: Assistant Director (Business Services) Accountable for: Day to day leadership of team members

More information

Structured process improvements in facilities management organisations: Best practice case studies in the retail sector

Structured process improvements in facilities management organisations: Best practice case studies in the retail sector Structured process improvements in facilities management organisations: Best practice case studies in the retail sector Amaratunga, RDG, Haigh, RP and Baldry, D Title Authors Type URL Published Date 2005

More information

Julian Ashworth Software Product Services Ltd.

Julian Ashworth Software Product Services Ltd. Developing RADical SAS Applications Julian Ashworth Software Product Services Ltd. Higher quality, at lower cost, within a shorter time frame, are the pressures exerted on today's application developers.

More information

Defining Requirements

Defining Requirements Defining Requirements The scope of any project should represent the minimum amount of work needed to fulfil the customer s, or end user s requirements. Doing more work is wasteful; doing less means the

More information

Introduction to Software Engineering

Introduction to Software Engineering Introduction to Software Engineering 2. Requirements Collection Mircea F. Lungu Based on a lecture by Oscar Nierstrasz. Roadmap > The Requirements Engineering Process > Functional and non-functional requirements

More information

IEC Is it pain or gain?

IEC Is it pain or gain? IEC 61508 Is it pain or gain? Clive Timms, Director, C&C Technical Support Services Ltd. Introduction IEC 61508 (Ref. 1) provides designers and operators with the first generic internationally accepted

More information

Significant technology disruptions over the last decade

Significant technology disruptions over the last decade Significant technology disruptions over the last decade Services Portfolio What we deliver Human Capital Management Network Services Business continuity Wi- Fi Networks Business flexibility and scale Cloud

More information

Active Essex Risk Management Strategy

Active Essex Risk Management Strategy Active Essex Risk Management Strategy 2017-2021 November 2017 Contents 1. Policy Statement 2. Statement of Commitment 3. Risk Management Framework 4. Risk Appetite 5. Risk Maturity 6. Risk Management Levels

More information

Software Engineering II - Exercise

Software Engineering II - Exercise Software Engineering II - Exercise April 29 th 2009 Software Project Management Plan Bernd Bruegge Helmut Naughton Applied Software Engineering Technische Universitaet Muenchen http://wwwbrugge.in.tum.de

More information

Software Life Cycle. Main Topics. Introduction

Software Life Cycle. Main Topics. Introduction Software Life Cycle Main Topics Study the different life cycle models Study the difference between software maintenance and evolution Study product line engineering as a design methodology 2 Introduction

More information

Chapter 3 Software Process Model

Chapter 3 Software Process Model Usman Akram COMSATS Institute of information Technology lahore musmanakram@ciitlahore.edu.pk March 8, 2015 About software process model Outline 1 About software process model Build and Fix Model Why Models

More information

PRINCE Update. Changes to the manual. AXELOS.com. April 2017 PUBLIC

PRINCE Update. Changes to the manual. AXELOS.com. April 2017 PUBLIC PRINCE2 2017 Update s to the manual AXELOS.com April 2017 2 PRINCE2 2017 Update Contents 1 Introduction 3 2 Summary of changes 4 PRINCE2 2017 Update 3 1 Introduction This document provides a list of the

More information

version NDIA CMMI Conf 3.5 SE Tutorial RE - 1

version NDIA CMMI Conf 3.5 SE Tutorial RE - 1 Requirements Engineering SE Tutorial RE - 1 What Are Requirements? Customer s needs, expectations, and measures of effectiveness Items that are necessary, needed, or demanded Implicit or explicit criteria

More information

Chapter 6. Software Quality Management & Estimation

Chapter 6. Software Quality Management & Estimation Chapter 6 Software Quality Management & Estimation What is Quality Management Also called software quality assurance (SQA) s/w quality:- It is defined as the degree to which a system, components, or process

More information

6. Capability Maturity Method (CMM)

6. Capability Maturity Method (CMM) WAT IS TE C? 6. aturity ethod (C) Concept: The application of process management and quality improvement concepts to software development and maintenance odel: A model for organizational improvement Guidelines:

More information

Engineering 2503 Winter 2007

Engineering 2503 Winter 2007 Engineering 2503 Winter 2007 Engineering Design: Introduction to Product Design and Development Week 5: Part 1 Concept Selection Prof. Andy Fisher, PEng 1 Introduction The need to select one concept from

More information

Software Quality Management

Software Quality Management Software Quality Management Minsoo Ryu Hanyang University msryu@hanyang.ac.kr Outline Software Quality Model Software Quality Management Process and Quality Quality Metrics 2 2 What is Quality? Quality,

More information

KINGS COLLEGE OF ENGINEERING DEPARTMENT OF INFORMATION TECHNOLOGY QUESTION BANK

KINGS COLLEGE OF ENGINEERING DEPARTMENT OF INFORMATION TECHNOLOGY QUESTION BANK KINGS COLLEGE OF ENGINEERING DEPARTMENT OF INFORMATION TECHNOLOGY QUESTION BANK Subject Code & Subject Name: IT1251 Software Engineering and Quality Assurance Year / Sem : II / IV UNIT I SOFTWARE PRODUCT

More information

Success of Agile Environment in Complex Projects

Success of Agile Environment in Complex Projects Edith Cowan University Research Online Australian Information Warfare and Security Conference Conferences, Symposia and Campus Events 2010 Success of Agile Environment in Complex Projects Abbass Ghanbary

More information

Large Federal Agency Leverages IV&V to Achieve Quality Delivery for Critical Modernization Initiative

Large Federal Agency Leverages IV&V to Achieve Quality Delivery for Critical Modernization Initiative Large Federal Agency Leverages IV&V to Achieve Quality Delivery for Critical Modernization Initiative Capgemini Government Solutions provides Independent Verification and Validation (IV&V) services to

More information

Joined-up Requirements: Business Goals to System Tests

Joined-up Requirements: Business Goals to System Tests Joined-up Requirements: Business Goals to System s Case Study John Cheesman Strata Software john.cheesman@stratasoftware.com Strata Software Ltd 2005-2008 Strata Software Requirements specialists Requirements

More information

CMMI GLOSSARY A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

CMMI GLOSSARY A B C D E F G H I J K L M N O P Q R S T U V W X Y Z http://www.tutorialspoint.com/cmmi/cmmi-glossary.htm CMMI GLOSSARY Copyright tutorialspoint.com Here is the list of all CMMI Terms arranged in alphabetical order. A direct link is given based on first

More information

Introduction to Software Engineering

Introduction to Software Engineering UNIT I SOFTWARE PROCESS Introduction S/W Engineering Paradigm life cycle models (water fall, incremental, spiral, WINWIN spiral, evolutionary, prototyping, objects oriented) -system engineering computer

More information

Software Development Methodologies

Software Development Methodologies Software Development Methodologies Lecturer: Raman Ramsin Lecture 7 Agile Methodologies: Scrum 1 Agile Methodologies: Brief History First appeared in 1995. The once-common perception that agile methodologies

More information

PART THREE: Work Plan and IV&V Methodology (RFP 5.3.3)

PART THREE: Work Plan and IV&V Methodology (RFP 5.3.3) PART THREE: Work Plan and IV&V Methodology (RFP 5.3.3) 3.1 IV&V Methodology and Work Plan 3.1.1 NTT DATA IV&V Framework We believe that successful IV&V is more than just verification that the processes

More information

Oi Requirements Communication in New Product Development

Oi Requirements Communication in New Product Development Steer Your Development! Goal-Oriented Oi Requirements Communication in New Product Development September 9, 2008 Samuel Fricker, Tony Gorschek, Martin Glinz Product Manager in Context: Simplified, Stylized

More information

Selecting Software Development Life Cycles. Adapted from Chapter 4, Futrell

Selecting Software Development Life Cycles. Adapted from Chapter 4, Futrell Selecting Software Development Life Cycles Adapted from Chapter 4, Futrell Examples of Software Life Cycle Models Classical Waterfall Waterfall with feedback V-Shaped Prototyping Incremental Spiral Rapid

More information

7. Model based software architecture

7. Model based software architecture UNIT - III Model based software architectures: A Management perspective and technical perspective. Work Flows of the process: Software process workflows, Iteration workflows. Check Points of The process

More information

1 Introduction. 20 August 1995; 19:29 1 Master04.Doc

1 Introduction. 20 August 1995; 19:29 1 Master04.Doc 1 Introduction This master thesis concludes the study of computer science at the Rijks Universiteit of Leiden. The mentor for this project is dr. L.P.J. Groenewegen. The topic addressed in this master

More information

Planning and the Software Lifecycle. CSCE Lecture 2-08/26/2015

Planning and the Software Lifecycle. CSCE Lecture 2-08/26/2015 Planning and the Software Lifecycle CSCE 740 - Lecture 2-08/26/2015 Today s Goals Introduce software development processes Definitions - processes and process models Choosing a process AKA: planning and

More information

Poor customer experience costs $40 billion per year. Customer Experience Series Cost of Complaining

Poor customer experience costs $40 billion per year. Customer Experience Series Cost of Complaining Poor customer experience costs $40 billion per year Customer Experience Series Cost of Complaining Australian businesses are losing more than $720 for every negative customer experience The EY Customer

More information

Process Improvement. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 1

Process Improvement. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 1 Process Improvement Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 1 Objectives To explain the principles of software process improvement To explain how software process factors

More information

Wales Millennium Centre Behavioral Competencies Framework 1

Wales Millennium Centre Behavioral Competencies Framework 1 Wales Millennium Centre Behavioural Competencies Framework Be Reflective Ensuring we understand who our customers are Taking time to listen to customers Proactively engaging with customers to find out

More information

REQUIREMENTS FOR SAFETY RELATED SOFTWARE IN DEFENCE EQUIPMENT PART 1: REQUIREMENTS

REQUIREMENTS FOR SAFETY RELATED SOFTWARE IN DEFENCE EQUIPMENT PART 1: REQUIREMENTS Ministry of Defence Defence Standard 00-55(PART 1)/Issue 2 1 August 1997 REQUIREMENTS FOR SAFETY RELATED SOFTWARE IN DEFENCE EQUIPMENT PART 1: REQUIREMENTS This Part 1 of Def Stan 00-55 supersedes INTERIM

More information

ENGINEERS AUSTRALIA ACCREDITATION BOARD ACCREDITATION MANAGEMENT SYSTEM EDUCATION PROGRAMS AT THE LEVEL OF PROFESSIONAL ENGINEER

ENGINEERS AUSTRALIA ACCREDITATION BOARD ACCREDITATION MANAGEMENT SYSTEM EDUCATION PROGRAMS AT THE LEVEL OF PROFESSIONAL ENGINEER ENGINEERS AUSTRALIA ACCREDITATION BOARD ACCREDITATION MANAGEMENT SYSTEM EDUCATION PROGRAMS AT THE LEVEL OF PROFESSIONAL ENGINEER Document No. Title P05PE Australian Engineering Stage 1 Competency Standards

More information

EUROPEAN GUIDE TO INDUSTRIAL INNOVATION

EUROPEAN GUIDE TO INDUSTRIAL INNOVATION EUROPEAN GUIDE TO INDUSTRIAL INNOVATION Partners in Innovation Ltd (UK) have been awarded a contract by the European Commission to develop the European Guide to Industrial Innovation (GIDIE). The aim of

More information

Advantages and Disadvantages of. Independent Tests. Advantages. Disadvantages

Advantages and Disadvantages of. Independent Tests. Advantages. Disadvantages 8.0 Test Management Outline 8.1 Test organisation 8.2 Test planning and estimation 8.3 Test program monitoring and control 8.4 Configuration management 8.5 Risk and testing 8.6 Summary Independent Testing

More information

NOT PROTECTIVELY MARKED. HM Inspectorate of Constabulary in Scotland. Inspection Framework. Version 1.0 (September 2014)

NOT PROTECTIVELY MARKED. HM Inspectorate of Constabulary in Scotland. Inspection Framework. Version 1.0 (September 2014) HM Inspectorate of Constabulary in Scotland Inspection Framework Version 1.0 (September 2014) Improving Policing across Scotland Introduction I am pleased to introduce the new HMICS Inspection Framework.

More information

WORK PLAN AND IV&V METHODOLOGY Information Technology - Independent Verification and Validation RFP No IVV-B

WORK PLAN AND IV&V METHODOLOGY Information Technology - Independent Verification and Validation RFP No IVV-B 1. Work Plan & IV&V Methodology 1.1 Compass Solutions IV&V Approach The Compass Solutions Independent Verification and Validation approach is based on the Enterprise Performance Life Cycle (EPLC) framework

More information

Software Project Management Sixth Edition. Chapter Software process quality

Software Project Management Sixth Edition. Chapter Software process quality Software Project Management Sixth Edition Chapter 13.2 Software process quality 1 Product and Process Quality A good process is usually required to produce a good product. For manufactured goods, process

More information

Chapter 3. Information Systems Development. McGraw-Hill/Irwin. Copyright 2007 by The McGraw-Hill Companies, Inc. All rights reserved.

Chapter 3. Information Systems Development. McGraw-Hill/Irwin. Copyright 2007 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter 3 Information Systems Development McGraw-Hill/Irwin Copyright 2007 by The McGraw-Hill Companies, Inc. All rights reserved. Objectives 3-2 Describe the motivation for a system development process

More information

White Paper. Transforming Contact Centres using Simulation-based Scenario Modelling

White Paper. Transforming Contact Centres using Simulation-based Scenario Modelling White Paper Transforming Contact Centres using Simulation-based Scenario Modelling Meet Your KPI s, Deliver Consistently High Service and Reduce Customer Churn to Increase Your Bottom Line Results PM@SIMUL8.com

More information

Fuzzy Logic for Software Metric Models throughout the Development Life-Cycle

Fuzzy Logic for Software Metric Models throughout the Development Life-Cycle Full citation: Gray, A.R., & MacDonell, S.G. (1999) Fuzzy logic for software metric models throughout the development life-cycle, in Proceedings of the Annual Meeting of the North American Fuzzy Information

More information