Skip to main content

The Tar Pit - Summary

The author in this reading has compared the large-scale software project to the tar pit. Since the past decade, the reason behind the large-scale software projects not being able to meet the goals, schedules, and the assigned budget are the complex errors that arise during the development of such projects.
The author describes the following types of software products being developed around the world:
  •  Simple Program
    • The program is itself complete and ready for execution by its programmer on the system used for its development.
    • Usually, these types are projects are being developed by students as a semester project, or even as a final year project.
  • Programming Product
    • It can be executed, tested, repaired, and extended by anyone.
    • It is usable in many environments for many sets of data.
    • Generalized programs should be written in generalized fashion i.e. different ranges and form of input, and algorithms.
    • It is thoroughly documented for use and repair processes.
    • Developing this type of project from 'simple program' requires three times the original effort.
  • Programming System
    • It is a collection of interacting programs, coordinated in functionalities and disciplined in a format so that the assemblage continues of the entire facility for a large task.
    • Every input/output confirms in syntax and semantics with precisely defined interfaces.
    • It should only use a prescribed budget, and resources e.g. memory space, I/O devices, and computation time.
    • The product must be tested with other components in all possible test combinations possible.
    • The cost of the product is directly proportional to the number of components in the product.
    • Developing this type of project from 'simple program' requires three times the original effort.
  • Programming System Product
    • It is the combination of all of the above types thus making it the most useful.
    • These types of projects are the actual requirement of the client.
    • Developing this type of project from 'simple program' requires nine times the original effort.

Successful working of the program is possible if and only if the product is properly developed. Adjusting to the requirements for perfection is the most difficult part of learning to program. Other people set the one's objectives, provide resources and then furnish the one's information. One can rarely control its circumstances in his work or goals. According to the management ones, authority is insufficient for his responsibilities. In actual practice, authority is required from the very momentum of accomplishment.
  • Dependency of one on others can be harmful to programming as it can result in:
  • Mal-designed and poorly implemented program.
  • Incomplete delivery and poorly documented program.
  • The increase in maintenance cost.
With creativity comes hours of programming work. One finds debugging a linear work and expects somehow a quadratic approach to the end exists and can be adopted; thus leading to the increase in software testing time.
LONGER THE DEVELOPMENT TIME = OBSOLETE PROGRAMS
Advancements are the actual basis for the development of the program. If the design is done late resulting in the program becoming obsolete then:
  • Implementation of the product demands phasing and quantizing.
  • Absence of implementation must be measured against other existing implementations and not against unrealized concepts.
Therefore the goal is to determine a real solution to the real problem using the available resources and on an actual schedule.

Comments

Post a Comment

Popular posts from this blog

Software Architecture Views and Structures

Description of Views: In the year 1995 Kruchten presented his 4+1 architectural view model consisting of the following five types of views: Logical Development Process Physical Scenario Later with further development and research in the domain of architectural view following new views were developed to represent their respective structures: Views Sub-View of Description Logical None Highlights the functionalities provided by the system to the end-users. Unified Modeling Language (UML) diagrams such as the Class diagram, Domain diagram, Use Case diagram, State diagrams and Activity diagrams can be used to represent the logical view of the architecture. Development None It is also known as an implementation view. It is mainly concerned with the software project management. It represents the system with the programmer’s perspective. Process None It deals with the representation of...
2 comments
Read more

Overview of MISRA C++ (2008)

Introduction Software to Control Autonomous Car MISRA C ++ is a software development standard for C and C++ programming language that aims to facilitate code portability and reliability in the context of embedded systems, specifically those systems programming in ANSI C. Its mission is:  “   To provide assistance to the automotive industry in the application and creation within vehicle systems of safe and reliable software ” MISRA - A Brief History In 1998 MISRA targeted only the automotive industry but later released it focus on generic rules for developing safety-critical applications such as: anti-lock braking system  (ABS), and auto-pilot software system etc. No major changes have been made to the MISRA C++ standard after the version released in the year 2008. Every autonomous vehicle developed can only be allowed for commercial or industrial use if each of its hardware and software component adheres to the required standards. ...
1 comment
Read more

How traceability of non-functional requirements is managed throughout the software development process?

1. Requirements Traceability: Requirements traceability is the process of describing and keeping track of a set of requirements throughout the system’s lifecycle. The process assists in managing changing requirements of a particular software product. Requirements traceability of is two types, forward traceability where a particular requirement involved during the design and implementation phases of the software system, and backward requirement traceability where a particular requirement is being traced back to its source. 2. Proposed Solutions for the Traceability of Non - Functional Requirements : The author J. Merilinna [8], proposed a framework supported by a tool to trace the non-functional requirements in both forward and backward direction. The proposed method is based on the context of DSM (Domain Specific Modeling).  The NFR+1 framework involved are used for the elicitation, definition and redefinition of the system’s non-functional requirements. The...
4 comments
Read more