Computer Based Systems

Stand-Alone Systems

     Stand-alone software is any software application that does not come bundled with, or require, another software package in order to run. Essentially, it's software that can stand on its own without help from the internet or another computer process.

     You would typically install stand-alone software on your computer's hard drive, instead of using it as online software that runs via your internet browser.

     Examples of popular stand-alone software include Quicken and Microsoft Money. These two software packages don't require anything more than the operating system on your computer, whether it's Windows or another operating system.

Different Types of Stand-Alone Software

     Stand-alone software has certain defining characteristics. The following represent a few examples:

•      Software that runs on its own without an internet connection. Anti-virus software or financial software (like Microsoft Money) which can be installed on your computer after inserting an installation disc into your computer or laptop disc drive or portable disc drive. This helps you scan for viruses without the chance of an online virus re-infecting your computer. Having Microsoft Money installed on your computer means you can enter transactions at any time, without the need to be logged in to an internet connection.

•      Software that isn’t part of a bundle. Many times, software comes with computer hardware or electronic devices that you would use alongside your computer, such as a scanner. The software could serve as a full interface, such as a desktop program that works with a USB-enabled label printer. Otherwise, the software might consist only of a group of files used to install drivers and other files needed to make a peripheral piece of equipment, such as a laser printer, work with your computer. Conversely, a bundle typically means several types of software programs sold together, like the ones you receive already installed as a bundle when you purchase a new computer. 

•      A program that runs separately from all other computer processes. This type of program doesn’t rely on any other software in order to function. The most common example of this software type is your computer's operating system. While the operating system contains a large number of interrelated files, it runs on its own without needing any online files or other companion software.
•      A portable application that doesn’t need to be installed on your computer. An example is a software program that runs on its own using a disc or flash drive. When not in use, you can easily eject the disc or flash drive. You can keep the program self-contained, and it conveniently doesn't take up space on your hard drive. You might keep a program for virus removal on a separate flash drive so that you can use it if your computer stops functioning due to a bad virus. You might also keep the software on your flash drive that can "rescue" your computer by booting it from the flash drive instead of a potentially damaged hard drive.

•      An expansion pack for gaming. If you enjoy playing video games online, you know that gaming software offers expansion packs. In most cases, these packs come as “add-ons” to the original game. Add-ons might be new weapons, new characters, new lands, or other new items that can be incorporated into an existing game.

     Not all stand-alone software needs to be installed on your hard drive or run from an external device, such as a flash drive or disc. You can run certain small or simple software by running its executable file directly from the file location on your computer. Simply copy the executable file from an external source, save it any place on your computer, then double-click on it with your cursor to run the program. 

Pros and Cons

     Stand-alone software usually excels at giving you exactly what you need at a detailed level, because it's typically focused on providing a certain solution. Bundled or enterprise software often incorporates several types of functionality and sometimes suffers from trying to provide too many functions, with no depth in any of them.

     On the other hand, stand-alone software can create problems if you need to integrate it with other software packages because it was built to be used alone, and not as an add-on to other software.

Distributed Systems

     A distributed system contains multiple nodes that are physically separate but linked together using the network. All the nodes in this system communicate with each other and handle processes in tandem. Each of these nodes contains a small part of the distributed operating system software.

A diagram to better explain the distributed system is:

Types of Distributed Systems

     The nodes in the distributed systems can be arranged in the form of client/server systems or peer to peer systems. Details about these are as follows:

Client/Server Systems

     In client server systems, the client requests a resource and the server provides that resource. A server may serve multiple clients at the same time while a client is in contact with only one server. Both the client and server usually communicate via a computer network and so they are a part of distributed systems.

Peer to Peer Systems

     The peer to peer systems contains nodes that are equal participants in data sharing. All the tasks are equally divided between all the nodes. The nodes interact with each other as required as share resources. This is done with the help of a network.

Advantages of Distributed Systems

     Some advantages of Distributed Systems are as follows:

• All the nodes in the distributed system are connected to each other. So nodes can easily share data with other nodes.
• More nodes can easily be added to the distributed system i.e. it can be scaled as required.
• Failure of one node does not lead to the failure of the entire distributed system. Other nodes can still communicate with each other.
• Resources like printers can be shared with multiple nodes rather than being restricted to just one.

Disadvantages of Distributed Systems

     Some disadvantages of Distributed Systems are as follows:

• It is difficult to provide adequate security in distributed systems because the nodes as well as the connections need to be secured.
• Some messages and data can be lost in the network while moving from one node to another.
• The database connected to the distributed systems is quite complicated and difficult to handle as compared to a single user system.
• Overloading may occur in the network if all the nodes of the distributed system try to send data at once.

Dependency Management

What is dependency management?

     Software projects rarely work in isolation. In most cases, a project relies on reusable functionality in the form of libraries or is broken up into individual components to compose a modularized system. Dependency management is a technique for declaring, resolving and using dependencies required by the project in an automated fashion. Dependency management is a very important discipline for a project manager.  It is the “D” in RAIDs management.In simple terms, a dependency is where a task, milestone or activity is dependent on another task or milestone being completed before it can start or be completed.

     It is possible for a project to have intra-dependencies. This is where tasks, milestones, etc within the same project are dependent on each other. The other type of dependency is external. This is where the dependency is on a different project, programme or even business as usual.

     A project manager must be aware of all of the dependencies for their project.  The reason is simple, if a dependency is not met, the successful delivery of the project may be threatened.

     A smart project manager should call on the services of the  PMO, a good, value adding PMO will be able to facilitate and manage external dependencies as a project manager should have the empowerment and oversight to manage intradependencies.

How to capture dependencies

     You will see lots of articles and diagrams that show wonderful process flows for managing dependencies. However, the real skill is identifying what are the dependencies that need to be worried about. This is not an exact science and difficult to fully document. However, the following to be a good approach.

1. Awareness sessions

     Get all of the projects and programmes into a workshop, ideally no more than 2 hours. Ahead of the meeting get each project to prepare a one page slide using a standard format. This should provide:

• Project name
• Sponsor
• Project Manager
• Start / end dates
• Current status
• Business area / function
• Overview of the project
• Business process being changed
• Platforms being implemented / changed
• Key milestones
• Key issues / risks

     In the actual meeting, the PMO lead should set the scene by stating the purpose of the session is to identify any dependencies between projects.  Each sponsor / project manager will then briefly discus their project.  This will allow other project managers to ask questions and identify potential dependencies i.e. where 2 different projects are trying to change the same system at the same time.

At the end of the session you should have:

• List of potential dependencies
• Possible dependencies with clear actions for the appropriate project managers to discus after meeting

     The PMO can then spend time reviewing and cleansing the list.  Working out the exact milestones where the dependency exists and then play this back to the project managers to agree

2. Agree dependencies

     When all of the dependencies have been captured, it is then necessary to work with the project managers on either side of a dependency to confirm and agree that the dates are realistic and achievable.  If not, one of the projects will probably need to re-plan.  The aim is to have all parties in agreement on the delivery date.

3. Monitor and control

     The now should be a clear view of dependencies and the associated milestones in the different plans.  The PMO should track progress against these critical milestones as part of the regular meetings and reporting.  When a milestone looks like it is slipping, they can quickly explore if it will be missed and then start the dialogue with the receiving project so as to assess impact and mitigating actions. However, it is important that each project manager monitors the dependencies that are important for their project.  The same way risks and issues should be reviewed, the project manager and / or the project team should check to make sure that all deliveries on which they are dependent, are on track.

Dependency tools

• Unique Reference – used to identify dependency

• Description – used to briefly describe the dependency

• Enabling Programme / Project – who must deliver the task, milestone, etc (sometimes known as the ‘giver’)

• Task / Milestone Description – details of the exact milestone / Task that must be delivered

• Dependent Programme – who needs the task, milestone to be delivered (sometimes known as the ‘receiver’)

• Dependent Task / Milestone – details of milestone / task that needs the delivery

• Delivery Date – date dependency must be delivered by to not cause a delay in dependent project

• Probability – probability that dependency will not be met in required timeline

• Impact – impact of dependency not being delivered in required timeline

• Status – open, closed, etc

• Owner – who owns the dependency

• Date Raised – date dependency was raised

     In a similar way to the management of risks, issues and assumptions, the simple method of recording and monitoring dependencies is by using a dependency register. This should typically capture: Other fields can be added to indicate if dependency is on the critical path, etc. However, the above fields should allow for the management of external dependencies.

1. NPM

     I couldn’t write this guide without giving credit to the Node Package Manager. Built on Node.js, this system powers a tremendous repository of 100,000+ packages and modules.

     Each project can use a package.json file setup through NPM and even managed with Gulp(on Node). Dependencies can be updated and optimized right from the terminal. And you can build new projects with dependency files and version numbers automatically pulled from the package.json file. NPM is valuable for more than just dependency management, and it’s practically a must-know tool for modern web development. If you’re confused please check out this Reddit thread for a beginner’s explanation.

2. Bower

     The package management system Bower runs on NPM which seems a little redundant but there is a difference between the two, notably that NPM offers more features while Bower aims for a reduction in filesize and load times for frontend dependencies.

     Some devs argue that Bower is basically obsolete since it runs on NPM, a service that can do almost everything Bower can do. Generally speaking this isn’t wrong. But devs should realize Bower can optimize the workflow specifically with frontend dependencies. I recommend Ben McCormick’s article Is Bower Usefulto learn more about the value offered from both package management tools.

3. RubyGems

     RubyGems is a package manager for Ruby with a high popularity among web developers. The project is open source and inclusive of all free Ruby gems. To give a brief overview for beginners, a “gem” is just some code that runs on a Ruby environment. This can lead to programs like Bundler which manage gem versions and keep everything updated.

     Rails developers will love this feature, but what about frontend packages? Since Ruby is open source, developers can build projects like Bower for Rails. This brings frontend package management to the Ruby platform with a small learning curve.

4. RequireJS

     There’s something special about RequireJS in that it’s primarily a JS toolset. It can be used for loading JS modules quickly including Node modules. RequireJS can automatically detect required dependencies based on what you’re using so this might be akin to classic software programming in C/C++ where libraries are included with further libraries.

     You’ll find an interesting GitHub discussion on this topic and the value it offers modern web developers. Granted other JS management tools like webpack have popped up, RequireJS still works in production environments. And if it works for you that’s all that matters.

5. Jam

     Browser-based package management comes in a new form with JamJS. This is a JavaScript package manager with automatic management similar to RequireJS. All your dependencies are pulled into a single JS file which lets you add and remove items quickly. Plus these can be updated in the browser regardless of other tools you’re using (like RequireJS).

     Libraries are updated based on the latest versions through the terminal. Each project can be created automatically with optimized components based on your needs. Jam is free on GitHub and worth a look if you have the time.

6. Browserify

     Most developers know of Browserify even if it’s not part of their typical workflow. This is another dependency management tool which optimizes required modules and libraries by bundling them together. These bundles are supported in the browser which means you can include and merge modules with plain JavaScript. All you need is NPM to get started and then Browserify to get moving.

7. Mantri

     Still in its early stages of growth, MantriJS is a dependency system for mid-to-high level web applications. Dependencies are managed through namespaces and organized functionally to avoid collisions and reduce clutter.

     Mantri is currently at v0.2.2 at the time of writing. It’s completely open sourceand built for more complex web applications that require large bundles of dependencies. Mantri aims to follow modular programming practices and hopes to encourage developers onto the same path.

8. Volo

     The project management tool volo is an open source NPM repo that can create projects, add libraries, and automate workflows. Volo runs inside Node and relies on JavaScript for project management. A brief intro guide can be found on GitHub explaining the installation process and common usage. For example if you run the command volo create you can affix any library like HTML5 Boilerplate.

     But aside from creating new projects you can also add/update libraries for older projects. Volo ties into everything you would need for frontend development. Check out volo’s design goals to see how it operates in a real-world project.

9. Ender

     Ender is the “no-library library” and is one of the lightest package managers you’ll find online. It allows devs to search through JS packages and install/compile them right from the command line. Ender is thought of as “NPM’s little sister” by the dev team.

     Naturally the whole Ender framework is available for free on GitHub. It’s simply a tool that you install to help manage consumption of frontend JavaScript frameworks for local projects. Everything is meant to run with ease to the fullest potential for a frontend developer’s workflow. The main Ender website has quality documentation so it’s worth a glance if you’re interested.

10. pip

     The recommended method for installing Python dependencies is through pip. This tool was created by the Python Packaging Authority and it’s completely open source just like Python itself.

     The majority of Python developers recommend pip for dependencies including the Django team. Whether you’re just getting started with Python or already use it consistently with backend development, this is a package manager you’ll be glad to have in your toolbox.

11. Composer

     Composer is a package manager very similar to NPM, but it’s focused solely on PHP libraries. You can find a list of dependencies on Packagist which includes large PHP frameworks such as Laravel. If you’re a PHP developer of any kind I seriously recommend looking into Composer. It’s easy to get started but difficult to fit into your workflow. However with practice it’ll become a staple for PHP dev projects.

     This is a versatile tool with the potential to grow even larger in time. Plus NPM can mix with Composer to create a frontend + backend dependency management system for all your PHP/JS projects.

Version Controlling in Programming

Introduction to version control

     If you are already familiar with version control, you can skim or skip this section. A version control system serves the following purposes, among others.

• Version control enables multiple people to simultaneously work on a single project. Each person edits his or her own copy of the files and chooses when to share those changes with the rest of the team. Thus, temporary or partial edits by one person do not interfere with another person's work.
  Version control also enables one person you to use multiple computers to work on a project, so it is valuable even if you are working by yourself.
• Version control integrates work done simultaneously by different team members. In most cases, edits to different files or even the same file can be combined without losing any work. In rare cases, when two people make conflicting edits to the same line of a file, then the version control system requests human assistance in deciding what to do.
• Version control gives access to historical versions of your project. This is insurance against computer crashes or data lossage. If you make a mistake, you can roll back to a previous version. You can reproduce and understand a bug report on a past version of your software. You can also undo specific edits without losing all the work that was done in the meanwhile. For any part of a file, you can determine when, why, and by whom it was ever edited.

Repositories and working copies

     Version control uses a repository (a database of changes) and a working copy where you do your work.

Your working copy (sometimes called a checkout) is your personal copy of all the files in the project. You make arbitrary edits to this copy, without affecting your teammates. When you are happy with your edits, you commit your changes to a repository.

     A repository is a database of all the edits to, and/or historical versions (snapshots) of, your project. It is possible for the repository to contain edits that have not yet been applied to your working copy. You can update your working copy to incorporate any new edits or versions that have been added to the repository since the last time you updated. See the diagram at the right.

     In the simplest case, the database contains a linear history: each change is made after the previous one. Another possibility is that different users made edits simultaneously (this is sometimes called “branching”). In that case, the version history splits and then merges again. The picture below gives examples.

What is Version Control System?

     A version control system allows users to keep track of the changes in software development projects, and enable them to collaborate on those projects. Using it, the developers can work together on code and separate their tasks through branches.

     There can be several branches in a version control system, according to the number of collaborators. The branches maintain individuality as the code changes remain in a specified branch(s).

     Developers can combine the code changes when required. Further, they can view the history of changes, go back to the previous version(s) and use/manage code in the desired fashion.

Distributed and centralized version control

     There are two general varieties of version control: centralized and distributed. Distributed version control is more modern, runs faster, is less prone to errors, has more features, and is somewhat more complex to understand. You will need to decide whether the extra complexity is worthwhile for you.

Some popular version control systems are Git (distributed), Mercurial (distributed), and Subversion (centralized).

     The main difference between centralized and distributed version control is the number of repositories. In centralized version control, there is just one repository, and in distributed version control, there are multiple repositories. Here are pictures of the typical arrangements:

         

     In centralized version control, each user gets his or her own working copy, but there is just one central repository. As soon as you commit, it is possible for your co-workers to update and to see your changes. For others to see your changes, 2 things must happen:

• You commit
• They update

     In distributed version control, each user gets his or her own repository and working copy. After you commit, others have no access to your changes until you push your changes to the central repository. When you update, you do not get others' changes unless you have first pulled those changes into your repository. For others to see your changes, 4 things must happen:

• You commit
• You push
• They pull
• They update

     Notice that the commit and update commands only move changes between the working copy and the local repository, without affecting any other repository. By contrast, the push and pull commands move changes between the local repository and the central repository, without affecting your working copy.

It is sometimes convenient to perform both pull and update, to get all the latest changes from the central repository into your working copy. The hg fetch and git pull commands do both pull and update. (In other words, git pull does not follow the description above, and git push and git pull commands are not symmetric. git push is as above and only affects repositories, but git pull is like hg fetch: it affects both repositories and the working copy, performs merges, etc.)

Local Version Control Systems

     Many people’s version-control method of choice is to copy files into another directory (perhaps a time-stamped directory, if they’re clever). This approach is very common because it is so simple, but it is also incredibly error prone. It is easy to forget which directory you’re in and accidentally write to the wrong file or copy over files you don’t mean to.

    To deal with this issue, programmers long ago developed local VCSs that had a simple database that kept all the changes to files under revision control.

     One of the most popular VCS tools was a system called RCS, which is still distributed with many computers today. RCS works by keeping patch sets (that is, the differences between files) in a special format on disk; it can then re-create what any file looked like at any point in time by adding up all the patches.

Centerlized Version Control Systems

     The next major issue that people encounter is that they need to collaborate with developers on other systems. To deal with this problem, Centralized Version Control Systems (CVCSs) were developed. These systems (such as CVS, Subversion, and Perforce) have a single server that contains all the versioned files, and a number of clients that check out files from that central place. For many years, this has been the standard for version control.

     This setup offers many advantages, especially over local VCSs. For example, everyone knows to a certain degree what everyone else on the project is doing. Administrators have fine-grained control over who can do what, and it’s far easier to administer a CVCS than it is to deal with local databases on every client.

     However, this setup also has some serious downsides. The most obvious is the single point of failure that the centralized server represents. If that server goes down for an hour, then during that hour nobody can collaborate at all or save versioned changes to anything they’re working on. If the hard disk the central database is on becomes corrupted, and proper backups haven’t been kept, you lose absolutely everything — the entire history of the project except whatever single snapshots people happen to have on their local machines. Local VCS systems suffer from this same problem — whenever you have the entire history of the project in a single place, you risk losing everything.

Distributed Version Control Systems

     This is where Distributed Version Control Systems (DVCSs) step in. In a DVCS (such as Git, Mercurial, Bazaar or Darcs), clients don’t just check out the latest snapshot of the files; rather, they fully mirror the repository, including its full history. Thus, if any server dies, and these systems were collaborating via that server, any of the client repositories can be copied back up to the server to restore it. Every clone is really a full backup of all the data.

     Furthermore, many of these systems deal pretty well with having several remote repositories they can work with, so you can collaborate with different groups of people in different ways simultaneously within the same project. This allows you to set up several types of workflows that aren’t possible in centralized systems, such as hierarchical models.

Benifits of Version Control Systems

     Developing software without using version control is risky, like not having backups. Version control can also enable developers to move faster and it allows software teams to preserve efficiency and agility as the team scales to include more developers.

     Version Control Systems (VCS) have seen great improvements over the past few decades and some are better than others. VCS are sometimes known as SCM (Source Code Management) tools or RCS (Revision Control System). One of the most popular VCS tools in use today is called Git. Git is a Distributed VCS, a category known as DVCS, more on that later. Like many of the most popular VCS systems available today, Git is free and open source. Regardless of what they are called, or which system is used, the primary benefits you should expect from version control are as follows.

1. A complete long-term change history of every file. This means every change made by many individuals over the years. Changes include the creation and deletion of files as well as edits to their contents. Different VCS tools differ on how well they handle renaming and moving of files. This history should also include the author, date and written notes on the purpose of each change. Having the complete history enables going back to previous versions to help in root cause analysis for bugs and it is crucial when needing to fix problems in older versions of software. If the software is being actively worked on, almost everything can be considered an "older version" of the software.
2. Branching and merging. Having team members work concurrently is a no-brainer, but even individuals working on their own can benefit from the ability to work on independent streams of changes. Creating a "branch" in VCS tools keeps multiple streams of work independent from each other while also providing the facility to merge that work back together, enabling developers to verify that the changes on each branch do not conflict. Many software teams adopt a practice of branching for each feature or perhaps branching for each release, or both. There are many different workflows that teams can choose from when they decide how to make use of branching and merging facilities in VCS.
3. Traceability. Being able to trace each change made to the software and connect it to project management and bug tracking software such as Jira, and being able to annotate each change with a message describing the purpose and intent of the change can help not only with root cause analysis and other forensics. Having the annotated history of the code at your fingertips when you are reading the code, trying to understand what it is doing and why it is so designed can enable developers to make correct and harmonious changes that are in accord with the intended long-term design of the system. This can be especially important for working effectively with legacy code and is crucial in enabling developers to estimate future work with any accuracy.

     While it is possible to develop software without using any version control, doing so subjects the project to a huge risk that no professional team would be advised to accept. So the question is not whether to use version control but which version control system to use.

Version control best practices

     The advice in this section applies to both centralized and distributed version control.

These best practices do not cover obscure or complex situations. Once you have mastered these practices, you can find more tips and tricks elsewhere on the Internet.

Use a descriptive commit message

     It only takes a moment to write a good commit message. This is useful when someone is examining the change, because it indicates the purpose of the change. This is useful when someone is looking for changes related to a given concept, because they can search through the commit messages.

Best Version Control Systems

     There are plenty of options available in the market. Hence, we have created a list of 10 best version control software to narrow the options and make things easier for you.

1. GitHub

     GitHub helps software teams to collaborate and maintain the entire history of code changes. You can track changes in code, turn back the clock to undo errors and share your efforts with other team members. It is a repository to host Git projects. For those wondering what is Git? It is an open source version control system that features local branching, multiple workflows, and convenient staging areas. Git version control is an easy to learn option and offers faster operation speed.

2. GitLab

     GitLab comes with a lot of handy features like an integrated project, a project website, etc. Using the continuous integration (CI) capabilities of GitLab, you can automatically test and deliver the code. You can access all the aspects of a project, view code, pull requests, and combine the conflict resolution.

3. Beanstalk

     Beanstalk is an ideal option for those who need to work from remote places. This software is based on browser and cloud, allowing users to code, commit, review and deploy using a browser. It can be integrated with messaging and email platforms for efficient collaborations related to codes and updates. It supports both Git and SVN and comes with built-in analytics features. For security, it leverages encryption, two-factor authentication, and password protection functionalities.

4. PerForce

     Perforce delivers the version control capabilities through its HelixCore. The HelixCore comes with a single platform for seamless team collaboration, and support for both centralized and distributed development workflows. It is a security solution that protects the most valuable assets. HelixCore allows you to track the code changes accurately and facilitates a complete Git ecosystem.

5. Apache Subversion

     Apache Subversion is another open source version control system, which was founded by CollabNet a couple of decades ago. Both open source arena and enterprises consider it a reliable option for valuable data. Key features of Subversion include inventory management, security management, history tracking, user access controls, cheap local branching, and workflow management.

6. AWS CodeCommit

     AWS CodeCommit is a managed version control system that hosts secure and scalable private Git repositories. It seamlessly connects with other products from Amazon Web Services (AWS) and hosts the code in secured AWS environments. Hence, it is a good fit for the existing users of AWS. AWS integration also provides access to several useful plugins from AWS partners, which helps in software development.

7. Microsoft Team Foundation Server

     Developed by Microsoft, the Team Foundation Server is an enterprise-grade tool to manage source code and other services that need versioning. It can keep track of work items to find defects, requirements, and scenarios in a project. It comes with several unique features like Team Build, data collection and reporting, Team Project Portal, Team Foundation Shared Services, etc.

8. Mercurial

     Mercurial is known for its efficiency in handling projects of all sizes. It is a free and distributed control management service that provides a simple and intuitive user interface. Developers and enterprises adore Mercurial for its backup system, search functionality, project tracking and management, data import and export, and data migration tool. It also features workflow management, history tracking, security management, access controls and more.

9. CVS Version Control (Concurrent Versions System)

     CVS is one of the oldest version control system and is a well-known tool among both commercial and open source developers. It allows you to check out the code you are planning to work on, and check-in the changes. It has the capability to handle projects with multiple branches so that teams can merge their code changes and contribute unique features to the project. Since CVS is here for a long time now, it is the most mature version control software.

10. Bitbucket

     Bitbucket is a part of the Atlassian software suite, so it can be integrated with other Atlassian services including HipChat, Jira, and Bamboo. The main features of Bitbucket are code branches, in-line commenting and discussions, and pull requests. It can be deployed on a local server, data center of the company, as well as on the cloud. Bitbucket allows you to connect with up to five users for free. This is good because you can try the platform for free before deciding to purchase.