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. Software Engineering and Development
  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
×

1763 results in Software Engineering and Development

Page 10 of 89

  • 5 - Project Knowledge Model: A Differentiator

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

  • Summary

    Having introduced PKM in chapter 4, this chapter presents its uniqueness in the project delivery environment.

    Digitisation of the project knowledge is the core proposition of PKM. This chapter continues to identify and detail the differentiators provided by PKM that accelerate the project delivery with enhanced quality. This chapter identifies the reasons why this model could not be visualised much earlier. Finally, it summarises the benefits that project delivery would accrue from the model.

    Project Knowledge Model Characteristics: Traceability and Flexibility

    Digitising project knowledge via traceability and in-built flexibility are the main characteristic of PKM.

    The completeness of the project knowledge is ensured by:

  • 1. Building block inventories (such as for requirement building bock, the inventory may be Requirement_01, Requirement_02) that can be completely specified by its mandatory and optional attributes (Requirement Id: mandatory field, Related department: optional field).

  • 2. Exhaustive traceability (171 to be precise, for a typical implementation) capturing links between the two inventories keep the knowledge digitised and integrated in a single repository. In a traditional project there may be up-to ten relationships of traceability. PKM provides the capability to manage up-to 171 relationships (for example) of traceability in the project helping specify the project knowledge completely.

    • There is a significant difference between relationship of the Project Knowledge Model and traceability used in traditional sense. In PKM, the inventory that is traced, represents the lowest logical unit of information. Its completeness is to the extent that when inventories are combined with linkages, it represents complete project knowledge. In traditional traceability, it is a challenge to represent inventories at the lowest and logically complete information, as they are unstructured sentences and paragraphs in sections of the documents, difficult to be traced unambiguously.

    In addition to being complete and fully traceable project knowledge, it is also flexible enough to cater for subjectivity as explained in the following:

  • 1. The number of building blocks is subjective and can vary based on the context and subjectivity of the SME.

  • 2. Attributes defining building blocks completely may be different for different organisations as they need to be evolved by the relevant SMEs.

  • 3. Many of the 171 relationships may not have much practical usage and hence can be de-scoped for greater speed of project delivery by the project SMEs. One example may be the relationship between the building blocks ‘Non-functional attributes’ and ‘Communication’.

  • 3 - Project Delivery Pain Areas and the Way Forward

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

  • Summary

    This chapter provides the context of the book and summarises how a new methodology of IT project delivery has evolved. It lists out some major failures of IT projects in the past, mentions the challenges in project delivery and identifies the root causes. It explains the reduced usage of the Waterfall project delivery methodology, having failed to keep project documents updated in real-time. It also explains the downgrading of the importance of project documentation in the Agile methodology. It introduces an alternate way of creating and maintaining project knowledge which is currently present in documents.

    Context

    Maturity in software project delivery is still low despite having numerous methodologies available to drive it. Methodologies generally fall under two families: Waterfall and Agile. The latest global data from the Standish Group [2], tracking over 50,000 projects during 2011–2015, shows that the success rate of Waterfall is 11% and Agile is 39%.

    The book has taken the scientific structure of Waterfall and the dynamic approach of Agile, combined it with PKM and evolved a new IT project delivery methodology, which I refer to as Knowledge Driven Development (KDD).

    An important reason for project failure is lack of availability of ‘fit-for-purpose’ information and timely communication across project stakeholders. In Waterfall methodology, the information and its communication are accomplished by project documents stored in a commonly accessible location. Documents change under version control with a sign-off mechanism, making it difficult to keep the document up-to-date in a continuously evolving project delivery environment. If a defect in the document is detected, say, today. It might take a month before the new version of the document is released addressing the defect (due to the sign-off mechanism). The other limiting factor is the document itself as it is written in free-form text and keeping it consistently updated involves significant effort. In Agile methodology, the situation is not better as the documents are not meant to be exhaustive enough to be considered as containing ‘fit-for-purpose’ information. The information is primarily communicated through face-to-face discussions, making it person dependent. Agile assumes fully skilled team members, and any attrition or absence might be a challenge. The only reliable source of information is code, which is written in technical language that only the technologists in the project can understand.

  • 7 - Extending Project Knowledge Model to Cover End-to-End Project Delivery – KDD

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

  • Summary

    This chapter shows how PKM drives project delivery. PKM is expanded to Extended PKM (EPKM) to include majority of execution and management related activities so that it can cover end-to-end project delivery. It gives rise to Knowledge Driven Development (KDD) – a new project delivery methodology.

    The chapter starts with understanding the broad scope of KDD in project delivery. Concepts important to appreciate KDD are detailed. The end-to-end project delivery phases are traversed using KDD via the standard quality gate approach. Other aspects of project delivery such as quality are also considered. Relevance of KDD across domain and types of projects are discussed. At the end, the chapter lists out differentiators that KDD is trying to bring in.

    Introduction

    As discussed in chapter 4, there are three types of activities in project delivery, i.e., relating to knowledge, execution and management. The project knowledge related activities are the most important and covered by PKM. PKM digitises the project knowledge to an extent that makes it possible to bring in similar digitisation in the activities related to execution and management. PKM can be extended to cover a majority of the execution and management related activities and a new project delivery method can be conceived. This has resulted in the evolution of Knowledge Driven Development or KDD.

    As discussed in chapter 2, there are three basic characteristics on which project delivery methodologies are based upon:

  • a. Structured or empirical

  • b. Sequential or iterative

  • c. Full delivery or delivery in increments

    • Waterfall is structured, sequential and typically full delivery in one go and Agile is empirical, iterative and incremental delivery. KDD can be categorised as:

  • a. Mix of structured (with its 189 data points of project knowledge) and empirical (evolved over the years based on experience, research and interaction with experts). The ideas may be intuitive but they are not proven yet and hence empirical.

  • b. Mix of sequential (solution design does not start before requirements are matured to a significant extent), non-sequential (test design and application design start in parallel after solution design) and iterative (once the project knowledge is specified completely, it becomes easy to create build and test execution into logical units, suitable for iteration).

  • b. c. It has the flexibility of full delivery and incremental delivery depending on need. Due to digital knowledge management, increments can be managed effectively.

  • 6 - Project Knowledge Model vs Project Documents

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

  • Summary

    Although this topic is touched upon in the previous chapters, this chapter concentrates on comparing PKM against project documents with respect to the creation and maintenance of project knowledge. It introduces both the mechanisms and provides an exhaustive comparison of the two from different perspectives. An example is provided for both document extract and PKM extract to aid understanding of their differences. It also details the artefact sets that can be extracted from PKM.

    Project Knowledge Model and Project Documents

    Figure 6.1 depicts how knowledge is managed in a typical project delivery from the perspectives of PKM and document production regime. Document production regime is based on Waterfall (structured) methodology. Agile methodology have a sleeker version of the document production regime.

    Any methodology of software development starts from gathering requirements and ends with the working software and the related specifications of the software. The traditional methodologies have been relying on document production regime for capturing specifications of the software from solution, technical and test perspective. In the Waterfall methodology, emphasis is given on rigorous maintenance of the documents during different phases of the project delivery. Agile methodology go for ‘fit-for-purpose’ documentation and documents are kept at high level so that they do not need frequent changes.

    As mentioned earlier, keeping the documents updated in real-time is a challenging task in project delivery and that causes a lot of gaps in communication, ultimately delaying the project. This is one reason the Agile methodology only go for high level documentation that does not need frequent updates.

    The main issue with the document production regime is that there is a need to update the contents of the documents regularly as the project progresses through different phases. But the problem is the before the updated document can be issued, it needs to be approved by the relevant stakeholders. The revised version of the documents is mostly issued on reaching selected milestones. For example, in Figure 6.1, six versions of BRS (Business Requirement Specification) are visualised over the course of the project delivery lifecycle. Let us say there is a gap of two months before the next version of the BRS is scheduled to be released. From the couple of days of release of the last version, the information contained in the document may not be the latest.

  • 15 - Global Relevance of KDD: GKMF Assisting Skill Development

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

  • Summary

    KDD, as an IT project delivery methodology, is still in its infancy and this book is the first attempt to bring the concept to the academia and industry. As it relates to knowledge, the concepts of KDD are also relevant to areas other than IT project delivery.

    In chapter 1, we have seen how knowledge is split into four levels that can be captured in eight building blocks. In chapter 4, we have seen how these eight building blocks, when customised to IT project delivery, become 18 building blocks. In this chapter we will reverse engineer 18 building blocks and understand how they comply with the Generic Knowledge Management Framework (GKMF) introduced in chapter 1. We will go through examples of KDD in action in areas other than software development.

    We will focus on the domain knowledge portion of GKMF. Through examples, we will demonstrate that GKMF has all the capability to grow into a skill development framework.

    KDD and Generic Knowledge Management Framework

    Let's recollect the Generic Knowledge Management Framework that we have introduced in chapter 1. Figure 15.1 is taken from chapter 1.

    The four levels of knowledge covering end-to-end knowledge are:

  • • Abstract knowledge: This is knowledge at the highest level of abstraction. It is manifested in universal truth and statement of fact at the highest level.

  • • Domain knowledge: It contains knowledge of the domains such as manufacturing, insurance and banking.

  • • Enterprise knowledge: This is the instantiation of domain knowledge for an organisation such as a banking company.

  • • Project knowledge: It keeps the enterprise knowledge continuously updated.

    • The level of knowledge is contextual and something at abstract knowledge level in one context can be at project knowledge level in another context.

    The respective stakeholders at these levels of knowledge are:

  • • Project knowledge: The project team of the organisation

  • • Enterprise knowledge: The IT and business teams of the organisation

  • • Domain knowledge: College students, for skill development relevant to an organisation

  • • Abstract knowledge: Students, for their basic education

  • The building blocks required to capture knowledge at various levels, as per GKMF are given in Figure 15.2.

    • When we apply this concept to software development, the number of building blocks changes to 18 for project knowledge as shown in Figure 15.3.

  • 4 - Project Knowledge Model: Context and Definition

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

  • Summary

    Project knowledge, which was notionally introduced in the previous chapters, is fully contextualised and defined in this chapter. The chapter begins by explaining what currently happens in the traditional project delivery regarding project knowledge. The complete definition of PKM is provided. At the end, an example of PKM is given to explain how it might look.

    Traditional Project Knowledge Management

    Knowledge, which is the combination of experience and research, is necessary to help IT industry, just as it is for all the other industries. IT industry will have two aspects: domain and technology. Domain is the collective knowledge, driven primarily by processes. Technology has implements such as programming languages that help putting that knowledge into useful outcome, most of the time it is software. Technology primarily helps in automating processes.

    The automation that typically results in creation of software, is delivered via a project or programme. Knowledge plays a crucial role in software development and consists of business and technical knowledge. Typically, a software development project consists of four knowledge-intensive phases. The phases along with the document representing that phase is listed below:

  • 1. Requirement analysis (business knowledge) – Business Requirement Specification Document

  • 2. Solution design (business knowledge) – Functional Specification Document

  • 3. Application design (technical knowledge) – High Level Design Document

  • 4. Test design (business knowledge) – Test Case Document

    • This combination of knowledge is called ‘Project Knowledge’. Let us now understand how the Waterfall and Agile methodologies manage this project knowledge.

    Project Knowledge Management in Waterfall Methodologies: Document Driven

    Project knowledge is managed in the Waterfall methodology using documents. The main documents representing project knowledge are:

  • 1. Business Requirement Specification (BRS) representing requirement analysis.

  • 2. Functional Specification Document (FSD) representing solution design.

  • 3. High Level Design (HLD) representing application design.

  • 4. Test Cases representing test design.

    • Documents are authored by relevant stakeholders and are subject to review by the project team and SMEs, who may or may not be part of the project team. Post review, the documents are singed off and once a document is signed-off, changes to it are managed by version control. The next version of the document is also subject to the review cycle. Every time the next version of the document is signed-off, the information needs to be communicated to the entire project team.

  • 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.

  • Appendix I - Hot Research Topics

  • Sandeep Bhowmik
  • Book:
    Cloud Computing
    Published online:
    31 August 2020
    Print publication:
    17 April 2017, pp 384-387

  • Summary

    A lot of research is happening in and around the field of cloud computing in order to achieve more efficient solutions to different issues and to gain optimal results from them. This section introduces a few, among many, hot research topics related to the wide domain of cloud computing.

    OPTIMAL MANAGEMENT OF CLOUD RESOURCE

    Resource management in cloud computing is the prime responsibility of the IaaS cloud service providers who build and manage the data centers. IaaS cloud provider has two major resource management objectives. First, to make the environment reliable as well as robust for optimal and efficient utilization of the data center infrastructure. The second is related to the SLA, which defines the relation with the consumer party.

    The first objective deals with issues like load balancing, fault tolerance, energy conservation etc. Here, the load should be distributed in a way that in a data center, the utilization rate remains in balance among resources of a similar type. To make a system fault tolerant, the allocation of the resources should happen in a way that the effect of the failure of some resource component remains insignificant. Energy conservation is another important issue while managing resources at a data center. Optimal energy use reduces computing cost and it should also be minimized to reduce the carbon footprint.

    A cloud provider may opt for a number of approaches to handle these issues. It can optimize these parameters by taking a combined approach, or it can work on every metric individually. The cloud provider may use some consistent set of combinations and/or may also decide to employ varied performance goals for individual operational situations. For instance, energy minimization may be a higher priority during low-load conditions, while the service performance may be the higher priority during high load. A balance should be maintained among all these choices without affecting the user expectations. Finding out an optimal balancing point between performance and energy conservation is a critical concern of the research in such cases.

    For resource management objectives related to the Service Level Agreements (SLA), the cloud providers generally adopt an approach called service differentiation. In this approach, different levels of service performances are delivered to different consumers depending on the service level agreements made with them.

  • 1 - Introduction

  • Sandeep Bhowmik
  • Book:
    Cloud Computing
    Published online:
    31 August 2020
    Print publication:
    17 April 2017, pp 1-18

  • Summary

    The catchword Cloud Computing may sound new to the arena of computing as well as information technology; although the concept behind it is not completely new. In a broad sense, it is a step (forward) to access the web-based services through Internet; or in general terms, cloud computing represents an advance in the field of computing technology where management of computing services is outsourced to greater extents and in multiple dimensions. To be specific, computing facilities are being made available as services offered by reputed vendors.

    Computing technology has been evolved over the years. There have been steady developments in the field of computing hardware, software architecture, web technology and network communications over the last decade. The speed of internetworks has increased day by day and it has also become cheaper. All these developments contributed in settinging the stage for the initiation of the revolutionary concept of ‘cloud computing’.

    Cloud computing has changed the way computation happens. It provides the means for smarter ways to do business and accordingly it makes life simpler. This chapter tries to highlight the shortcomings in the traditional computing approaches and it attempts to iterate how the stage was ready for the arrival of this new model of computing.

    Cloud computing has evolved over the years and has changed the way people live and do business over the World Wide Web.

    WHAT IS THE BUZZ ABOUT

    Cloud computing provides the means for users to easily avail computing facilities whenever and wherever required. They need not worry about setting up infrastructure, purchasing new equipment or investing in the procurement of licensed software. Rather they can access any volume, large or small, of computing facilities in exchange for some nominal payment. It is a new model of computing which has become possible through integration of advanced computing models, sophisticated web technologies and modern network communication technologies (especially high-speed Internet).

    Cloud computing became a hot topic for large computing vendors (companies like Amazon, Google, Microsoft etc.) only from mid-2008, but the concept itself is quite old. People have different perceptions regarding this new computing model. To some, it is a new and radical innovation.

Page 10 of 89