Skip to main content Accessibility help

We use cookies to distinguish you from other users and to provide you with a better experience on our websites. Close this message to accept cookies or find out how to manage your cookie settings.

Close cookie message
×
  1. Home
  2. Browse subjects
  3. Computer Science
  4. IT Management and Ecommerce
  5. Content listing

Refine search

Refine search

Access:
Content type:
Publication date:
Apply   From and To filters
Subject: Show more
Journals Show more
Publishers: Show more
Societies Show more
Series: Show more
Collections: Show more

Actions for selected content:

Select all | Deselect all
  • View selected items
  • Export citations
  • Download PDF (zip)
  • Save to Kindle
  • Save to Dropbox
  • Save to Google Drive

Save Search

You can save your searches here and later view and run them again in "My saved searches".

Please provide a title, maximum of 40 characters.
Cancel
×

413 results in IT Management and Ecommerce

Page 3 of 21

  • Preface

  • Dick Whittington, University of York
  • Book:
    Digital Innovation and Entrepreneurship
    Published online:
    06 December 2018
    Print publication:
    12 July 2018, pp xvii-xxii

  • Summary

    Most STEM students graduate with a rudimentary and anecdotal appreciation of how digital techniques, technologies and processes apply to business and entrepreneurship. This book bridges that gap. Some readers will have ambitions to start their own businesses, others will intend to join existing start-ups or larger organizations: all students need to understand how business works in the digital economy, to enhance the contribution they offer to a prospective employer. The book also provides a concise and practical introduction to digital innovation and entrepreneurship for those studying a more wide-reaching business study programme. It gives students a thorough grasp of the fundamentals of business in one volume, without the need for a full-blown business curriculum. It is effective with students of many disciplines and situations, from first-year undergraduates through to research staff and those entering the world of business. There are no assumed pre-requisites, other than a broad appreciation of the digital world. Every topic is introduced, explained and illustrated. Where relevant, references are provided to sources for further research or learning.

  • 7 - Intellectual Property and Protection

  • Dick Whittington, University of York
  • Book:
    Digital Innovation and Entrepreneurship
    Published online:
    06 December 2018
    Print publication:
    12 July 2018, pp 285-330

  • Summary

    This chapter is about ensuring a venture benefits from its capabilities and investment by maximizing the value of its intellectual property (IP) and managing risks from deliberate and accidental activity. Failure to protect can rapidly lead to damage and disruption, financial and reputational. It addresses the following: • Protection of IP – trademarks, registered designs, patents, copyright, open source – to establish and crystalize IP value and to protect it from abuse • Protection of confidential information – trade secrets, know-how, non-disclosure • Protection against onerous contracts: licensing, customer service, customer delivery • Protection against damage and intrusion – physical and cyber security • Protection against legal non-compliance – IP infringement, employment law, data protection Risks are illustrated and examined, and protective mechanisms described to enable a reasonable assessment of options and implications. Real-world examples are explained and the rolling case study is developed. The section that addresses protection against onerous contracts refers to three appendices of relevant contractual terms and their implications for the venture.

  • 9 - Key Themes and Summary Points

  • Dick Whittington, University of York
  • Book:
    Digital Innovation and Entrepreneurship
    Published online:
    06 December 2018
    Print publication:
    12 July 2018, pp 377-390

  • Summary

    This chapter collects and reflects upon ten key themes that emerge from previous chapters: • Set and agree the objectives and outcomes • Deliver something customers need • Create value from the ecosystem • Design the business to perform • Plan for growth and scalability • Build a culture with the right mix of talent • Distribute equity to motivate and reward investment • Control finances and know the runway • Understand and manage the risk envelope • Think like an investor in all matters For each of the key themes, a brief narrative summarizes its applicable contexts and picks out the principal points to be noted.

  • Appendix C: - Principal Terms of Customer Delivery Contracts

  • Dick Whittington, University of York
  • Book:
    Digital Innovation and Entrepreneurship
    Published online:
    06 December 2018
    Print publication:
    12 July 2018, pp 403-409

  • Summary

    There is a collection of customer delivery terms that it is particularly important to consider when agreeing a delivery contract with a customer. This Appendix gives explanations, cautions and in some cases, optional forms of words for the principal terms. It is important to note that the specific wording adopted may need to be reviewed in the light of applicable legal jurisdictions. Topics covered include: • Term of the project • Payment and payment terms • Defining the deliverables • Supplier’s obligations • Customer’s obligations • Project management • IP Rights • Confidentiality and non-disclosure • Change management • Liabilities • Warranties and disclaimers • Penalty clauses and liquidated damages • Termination • Non-poaching of staff • Assignment • Jurisdiction

  • 14 - Suits Factory Model: Needs Cultural Change

  • Manoj Kumar Lal
  • Book:
    Knowledge Driven Development
    Published online:
    20 October 2018
    Print publication:
    08 March 2018, pp 233-240

  • Summary

    KDD can drive the digitisation of project knowledge that may lead to standardising the processes of the project delivery. This may take the IT industry away from being knowledge-based and nearer to being a process-based industry. The factory model is suited to process-based industries and we can now say that KDD may enable IT industry to follow the factory model. However, changing from the current knowledge-based approach to factory approach is not simple. It needs greater appreciation of the digitisation of the project knowledge and a change in mindset to inspire the project team to work in the factory model. This chapter discusses these two topics in detail: enablement of the factory model for IT industry and the cultural change required to make it happen.

    Bringing IT Project Delivery Closer to Process-Based Industry

    Traditional project knowledge is contained in the following set of project documents:

  • a. Business Requirement Specification (BRS)

  • b. Functional Specification Document (FSD)

  • c. High Level Design Document (HLD)

  • d. Test Cases

    • KDD has digitised the project knowledge from these four documents to 189 data points. These data points are integrated with each other and provide a framework to manage the project knowledge via PKM. This will revolutionise the treatment of project knowledge and, in fact, commoditise it. This has brought software development closer to being a process-based industry from being a knowledge-based industry.

    Let us understand the document production regime of project knowledge by an example. As a business analyst, I have to produce the BRS document. When I start the day in office, I will have limited idea on how long it will take; I only have an indicative estimate to refer to. With my skills, experience and networking with my colleagues I will try to complete the BRS within the given time. If I am highly skilled and experienced, I can complete the work in half the time allocated and if I am a novice business analyst, it might even take more than twice the effort and the quality of work may not be fit-for-purpose. This is a typical situation while working in a knowledge-based industry.

    Let us now understand what typically happens in a factory. At the start of the day, the worker in the factory will get a target of specific output for the day.

  • Foreword

  • Manoj Kumar Lal
  • Book:
    Knowledge Driven Development
    Published online:
    20 October 2018
    Print publication:
    08 March 2018, pp xv-xviii

  • Summary

    When we think of the challenges in software engineering, we focus on the various technical activities: requirements, architecture, design, implementation, verification etc. Various management dimensions also receive attention: processes, planning, change management, quality, teamwork, competency, domain understanding, customer interaction, value focus and so on. Clearly, each one of these is very important, even critical, to successful software engineering.

    However, there is another dimension that is central to software engineering: contextual knowledge and how it flows through the engineering process, into the final product. It is easy to see why this dimension is central if we examine the nature and role of software. Software is the agent of operations for systems. It implements/enables the concept of functioning of its target system, which could be a business function, embedded system and/or user task. The technical activity stream in software engineering as a whole is aimed at developing this contextual knowledge about the target system, and then ensuring that it is addressed accurately and consistently by the resulting software solution.

    This book introduces Knowledge Driven Development (KDD), a path-breaking software engineering technology (best practice) that manages and ensures the systematic flow of contextual knowledge into software solution. As the author Manoj Kumar Lal illustrates beautifully through the case studies in Chapter 1, even software projects that diligently follow modern best practices are extremely likely to face challenges associated with managing this flow. The problem is that contextual knowledge evolves continuously as the project progresses (In Agile, this means that knowledge relating to software generated by a particular Sprint continues to evolve even after the Sprint completes), and that consistent shared understanding of relevant contextual knowledge needs to be maintained across all team members (even in large distributed teams) to avoid quality problems. Readers will find that the typical problems described by him are familiar to them as commonplace in the projects that they execute, and that these problems lead to significant productivity losses and quality problems. Every project, large or small, will benefit substantially from a structured approach to managing the consistent flow of contextual knowledge into software solutions.

    The book goes on to introduce precisely such a structured approach. Contextual knowledge about the target system is captured through a Project Knowledge Model (PKM) classified into 18 ‘building block’ types, and a further n2matrix of 171 possible relationships among them.

  • Overview of the Book

  • Manoj Kumar Lal
  • Book:
    Knowledge Driven Development
    Published online:
    20 October 2018
    Print publication:
    08 March 2018, pp xxv-xxx

  • Summary

    Generally, there are two types of people in the world: one who follow processes and methodologies as written in books, and the other who enjoy breaking rules and doing things differently. The latter can also be split into two categories: those with good intentions and those with bad intentions. The first category produces innovation and the second category produces criminal behaviour. Society has all these kinds of people. In a healthy society, a majority of people follow processes, some have honourable intentions in breaking rules and only a very few have criminal intentions.

    This is evident in software project delivery as well. Let's see how it happens there. Almost all projects select a project delivery methodology (there are many to choose from). There will be a set of people in the project who will understand the intent of the methodology and try to follow it while performing their assigned tasks. There will be another set of people who will have the maturity to understand that certain portions of the project delivery can be better accomplished by slightly tweaking the methodology steps and they will propose this to their colleagues. There will also be a few people who, for less honest reasons, will argue against the methodology steps or suggestions for change. They might propose something that will make their task easier, even if it becomes difficult for the majority of the team to accommodate their proposal. They will take excuses of someone's failure and justify delays from their side. They will create an opaque boundary around their work so that the transparency in the project progress is hindered.

    While there may be a majority of people falling under type one (process followers), there are significant number of people falling under the second type, category one (rule breakers with good intentions) and category two (rule breakers with bad or selfish intentions). A fine balance between all these types of people needs to be maintained by the project management. That is why success and failure of a project today is largely in the hands of the project manager, even if the team is highly skilled and experienced.

    Depending only on the project management to drive a project is not the best solution. The industry is keen to solve this issue at a strategic level. A major roadblock is that the IT industry is still knowledge-intensive.

  • 8 - Extended KDD: Pre-Requirement and Post Delivery

  • Manoj Kumar Lal
  • Book:
    Knowledge Driven Development
    Published online:
    20 October 2018
    Print publication:
    08 March 2018, pp 169-171

  • Summary

    In this chapter, we look at the product lifecycle rather than project lifecycle. Before a project starts via defined requirements, a business case must be established. Also, once the product is delivered, it is supported by the service management for support and maintenance until it is decommissioned. These two phases of the product delivery should also get the benefit from the concept of digital Project Knowledge Model. This chapter discusses the relevance of PKM in these two phases of the product delivery that can be covered by the Extended KDD.

    Business Case (Pre-Requirement)

    Cost of delivering software must be significantly less than the benefit it can deliver within a specified period, as determined by the customer. This makes the business case for the delivery of a software. A software delivery project usually passes through the business case before the requirement analysis phase of the project can start. Monetary considerations are always the key, either directly or indirectly. Indirect monetary considerations are obvious in regulatory and technology upgrade projects. Non-compliance with regulatory requirements might incur a heavy penalty, and technology upgrades, if not done, can result in unpredictable interruptions of services.

    There are usually two identifiable phases in the product delivery before the requirement analysis phase begins. They are:

  • 1. Initiation phase where an idea is generated and assessed for feasibility and cost-benefit. It goes through the scrutiny of the senior management to ensure it is as per the goals of the company and fit to go to the next phase.

  • 2. Concept phase, where As Is and To Be are detailed and, if needed, multiple solution options are arrived at. Out of them, one solution option is chosen, to be detailed further. There will always be a default option of not to do anything. For choosing a solution option, cost-benefit considerations are the key. Once a solution option is chosen, high level requirements are created, which become the input to the requirement analysis phase, which is the first phase of project delivery as detailed in the earlier chapters.

    • One of the biggest challenges in these early phases of product delivery is determining the size of the work. This is where the enterprise knowledge base of PKM comes to help. For each of these initial phases of initiation and concept, enterprise knowledge base can be used to size the work.

  • Appendix E - KDD: Response to Criticism

  • Manoj Kumar Lal
  • Book:
    Knowledge Driven Development
    Published online:
    20 October 2018
    Print publication:
    08 March 2018, pp 281-285

  • Summary

    Although KDD is not in the open forum for discussion about its merits and demerits (this book is the first attempt to take it to the industry and academia), while evolving this methodology and writing the book, it was exposed to many academicians and practitioners of software engineering. A list of concerns expressed by the experts and my responses to these concerns are given here.

    Criticism 1

    Computers cannot generate a fully readable document set representing complete project knowledge. Knowledge can never be fully defined (and will always be subjective) in a way that can be automated by a computer.

    Response

    Documents referred are related to project knowledge such as BRS, FSD, HLD and Test Cases. People who are sufficiently skilled in producing these documents have enough knowledge about them. But everyone has an individual style, whether it is writing, presenting or explaining. The personal experience of the author influences the document produced. Different people can present the same information differently. Some would write crisp and clear descriptions and some would write details covering detailed background information as well.

    This suggests that, because computers cannot think, they cannot produce a project document as the project documents need creative thinking. Computers can only process information based on algorithms and it is assumed that it is difficult to write an algorithm to capture knowledge.

    However, KDD has done something noteworthy. It has created a framework which defines and scopes the entire project knowledge. It expects the project team to capture the project knowledge using the same framework. It minimises the variations that are caused in a typical documentation regime. PKM provides a mechanism to capture the project knowledge in such a format which allows a computer to extract it in a document format.

    Let us appreciate the robustness of PKM. Any information related to the project can be captured completely via the combination of inventory and relationship. There are only two activities involved here. The first one is defining the inventory of a building block via a set of mandatory and optional attributes. The second one is linking all the inventories together. When all the inventories are traced, it clearly brings out their many-to-many relationships, completing the nested knowledge. This brings the rigour and maturity to the model which makes it easier for a computer to extract a document based on an algorithm.

  • 11 - Addressing Contemporary Concerns of Project Delivery

  • Manoj Kumar Lal
  • Book:
    Knowledge Driven Development
    Published online:
    20 October 2018
    Print publication:
    08 March 2018, pp 203-213

  • Summary

    As discussed in the earlier chapters, smooth project delivery is still a challenge and the IT industry is continuously working to make the project delivery more effective. This chapter discusses the relevance of KDD to important topics that are of interest for effective project delivery, other than DevOps and automation. The relevance of KDD to DevOps and automation has been discussed in separate chapters.

    Shift Left

    Shift Left refers to a practice in software development where teams focus on quality, work on prevention instead of detection and begin testing earlier than ever before. The goal is to increase quality, shorten long test cycles and reduce the possibility of unpleasant surprises towards the end of the development lifecycle.

    Following traditional methodologies results in a substantial testing phase of the project delivery, and significant effort is spent on rework due to oversights made in the pre-testing phases. KDD, via its negative relationships and manual review of the catalogued project knowledge elements (requirement, solution design, application design and test design) that are integrated via exhaustive traceability, creates an effective static testing environment that has been largely absent in the existing methodologies.

    The cost of quality in a typical project is close to 50% (in my experience) with the break-up as follows:

  • 1. About 25% effort goes in in test design, execution and management.

  • 2. One-third of the remaining 75% effort typically goes towards review and rework.

    • Shift left aims to optimise this one third of the remaining effort so that the test execution can be almost defect free. KDD reduces this one third of the review and rework effort through the catalogued knowledge capturing mechanism, the negative relationships review and manual review. Its benefits are:

  • 1. Review and rework is digitised via 516 data points of project knowledge and the related quality assurance. Due to the scientific way of handling review and rework, KDD reduces this effort up to 50% of the existing effort.

  • 2. Test cases are prepared by reusing inventories of solution design. OATS technique is used for optimised coverage. The entire set of test cases (from unit test to UAT) is prepared at one go and in the same format. Considering traditional end-to-end test design by different teams, the KDD approach has the potential to reduce the efforts spent in test design by half.

  • Preface

  • Manoj Kumar Lal
  • Book:
    Knowledge Driven Development
    Published online:
    20 October 2018
    Print publication:
    08 March 2018, pp xix-xxii

  • Summary

    Let's visualise IT project delivery as consisting of two segments. The first, dealing with requirement gathering and analysis, and detailing the solution from the business and technical perspective. The second, dealing with coding, testing and implementing the software. The first represents project knowledge and the second relates to its technical implementation. Software engineering focuses on both. While there has been a significant advancement in technical implementation, project knowledge has not matured at the same rate. Project knowledge is still plagued with gaps in effective representation, communication, competency and quality assurance, and there is significant opportunity to improve this area.

    We try to manage project knowledge largely through experienced associates, strong adherence to processes and documentation, and robust communication with stakeholders. In this book, I have gone deeper into this by decomposing knowledge and representing it via data points. I have conceptualised the Project Knowledge Model (PKM) to manage the project knowledge in a structured manner. PKM catalogues the entire project knowledge and integrates it together with an exhaustive traceability mechanism. PKM has the potential to assist all the existing project delivery methodologies. It digitises project knowledge which, in turn, assists in the technical implementation of the software as well.

    I have expanded PKM to cover end-to-end project delivery and evolved a new methodology of project delivery, named Knowledge Driven Development (KDD). KDD is driven by PKM and blends the Waterfall and Agile project delivery concepts. The bridging of the gap between Waterfall and Agile project delivery is an underlying theme that runs throughout this book and is a positive spin-off from the digitisation of project knowledge.

    Taking the knowledge decomposition concept beyond IT, I have also evolved a Generic Knowledge Management Framework (GKMF) which has the potential to manage generic knowledge and assist in skill development.

    This book introduces PKM, KDD and GKMF with a case study and examples. It elaborates PKM and explains how the model may help the project delivery, regardless of the project delivery methodology followed. The idea is still conceptual and untested but matured enough to be presentable. Objective of this book is to present the idea in a meaningful manner to enable further work on it.

    What inspired me the most to work towards this methodology were the numerous instances of lost time, misdirected effort and the ensuing delays in project delivery.

Page 3 of 21