Skip to main content Accessibility help
×
  1. Home
  2. Browse subjects
  3. Engineering
  4. Electronic, optoelectronic devices, and nanotechnology
  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
×

5077 results in Electronic, optoelectronic devices, and nanotechnology

Page 70 of 254

  • Appendix C - Project Estimate and Business Rule/Scenario Framework

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

  • Summary

    One of the biggest issues that the IT industry is facing today is the lack of an effective mechanism for sizing a project. There are many techniques existing to size projects which are sometimes dependent on the technology used for the software and sometimes not. The main project sizing mechanisms are:

  • • Function Point estimate: The function point is a unit of measurement to express the amount of business functionality an information system (as a product) provides to a user. Function points are used to compute a functional size measurement of software. The sizing is independent of technology.

  • • Feature Point estimate: It is a modified function point to improve applicability to systems with significant internal processing (e.g., operating systems, communication systems). This allows accounting for functions not readily perceivable by the user, but essential for proper operations. The sizing is independent of the technology.

  • • Use Case based estimate: Use case represents the functional aspect of the project. The use cases and their complexity add up to scope the project and determine the size of the project. The sizing is independent of the technology.

  • • Component based estimate: The software is broken into multiple, manageable IT components and an estimate is done for each of the IT components. The technology influences the sizing.

  • • Line of Code: Line of code is another mechanism that determines the size of the software. The technology influences the sizing.

    • In practice, these methods are not very popular with the project teams. Estimates are still the prerogative of the SMEs, who often get them wrong. Techniques like Work Breakdown Structure (WBS) that calculate effort and not the software size are still widely used to estimate a project.

    If we look at the three technology independent software sizing techniques (function point, feature point and use case), it becomes clear that they are primarily trying to count the functionality of the software. They represent the unit of project knowledge for sizing the software. As explained in chapter 15, a combination of business rule and scenario can be used to represent project knowledge. Combination of business rule and scenario is more suitable to become the basis of sizing a project – a well researched discovery made in the book as explained via GKMF and Lean KDD.

  • 2 - Project Delivery and Supporting Methodologies

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

  • Summary

    This chapter introduces the reader to the technology and domain aspects of an industry and then details it for IT industry. It elaborates the knowledge-based nature of the IT industry and the factors limiting its natural movement to a process-based industry. It then provides a general overview of the IT project delivery. It also lists project delivery methodologies, standards, guidelines and frameworks used in various scenarios to manage the IT projects.

    IT Industry from Technology and Domain Perspective

    Information Technology (IT) is nascent industry. Let us look at various industries and their ages:

  • 1. Agriculture (12,000 years old)

  • 2. Modern Banking Industry (700 years old)

  • 3. Modern Insurance Industry (350 years old)

  • 4. Modern Pharmaceutical Industry (200 years old)

  • 5. Modern Steel Industry (150 years old)

  • 6. Information Technology (60 years old)

    • Industries have matured with research and experience contributing to enrichment of knowledge in the industry. Old industries have matured enough to have standard and well-defined processes for delivery of various projects. Also, their processes are not generic but detailed and prescriptive. For example, in an agricultural plantation, separation between two plants is well-defined and prescriptive. It primarily depends on plant types. But this would not have been the case a few thousand years ago. At that time the practice must have gone through several phases of research and experience to come to the optimal separation between two plants. Agriculture, then, could be termed as a knowledge-based industry but now it is a process-based industry.

    One of the greatest revolutions in the maturity of industries has been the Industrial Revolution where mechanisation proved immensely beneficial for mass production. Another revolution of a similar or even greater scale is being brought about by the introduction of computers (including smartphones and apps), which has started impacting every aspect of our lives. Computers have brought in the IT industry to the fore.

    The IT industry itself is a new industry and is barely 60 years old. IT is a support industry which assists other industries. Predominantly, IT automates manual, repeatable processes via software.

    An industry has two components at the highest level. These are the implements and the way of using the implements effectively. The implement in IT is ‘technology’ and the knowledge about how to effectively use an implement is ‘domain’.

  • 10 - Enabling DevOps

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

  • Summary

    DevOps is becoming an increasingly popular concept, trying to optimise the product lifecycle, rather than the product development lifecycle, where the development team and service management team are seamlessly integrated. This chapter tries to understand the details of DevOps, issues in the product lifecycle it is trying to solve and how KDD supports DevOps.

    What Is DevOps

    Before the advent of the personal computers, it was almost the same team that used to develop the software and maintain it, until its decommissioning. The advent of personal computers and other advancements in technology led to the specialisation of skills and the formation of development, quality assurance and service management teams. The IT organisation structure has been based on functional specialisations since then. This structure initiated the development of the popular handover-takeover mechanism to pass information from one team to the other. This mechanism has limited effectiveness, as during handover-takeover, it is practically impossible to pass on all the knowledge that is gathered by one team to the other. Often, the functional splitting of the project acts as a barrier to the work rather than being the enabler of project delivery as widely observed in Waterfall methodology.

    The Agile methodology has brought significant improvement in the way software is developed. For example, Agile forms a joint project development team which is co-located and works together for the success of the project. Formal handover-takeover is no longer needed as the teams are physically or virtually co-located. This has made a working style possible that was difficult to imagine a couple of years ago. For example, testers in a Sprint team do not usually raise a defect. They come to developers, discuss and resolve the issue directly, saving a lot of effort in this way.

    However, Agile, like Waterfall, focuses on project delivery. Agile hands over the project knowledge in the form of minimal documents and Waterfall hands over exhaustive documentation that may not be kept updated to service management team. Neither of these two scenarios are ideal from the service management team perspective. There is a need to look into optimising the entire lifecycle of the product and not only product development. In the product lifecycle, the three most important stakeholders are:

  • • Development team (includes business analysts), which develops the product.

  • • Quality Assurance team, which ensures the product is as per the specifications of the customer.

Page 70 of 254