Software Maintenance and Support

 

“Begin with the end in mind”

Maintenance and support will continue for the life of your software system. A significant portion of the system’s life-cycle budget will be consumed by these tasks. In fact, experts estimate that Maintenance can eventually account for 40 to 80% of the total project cost.

What is Maintenance?

 

This phase of the software lifecycle consists of the tasks required to keep your system operational after it is delivered into Production.

Software maintenance cost is derived from the changes made to software after it has been delivered to the end user. Software does not “wear out” but it will become less useful as it gets older, plus there WILL always be issues within the software itself.

The different types of maintenance tasks are described as:

  1. Corrective – Updates that are required to correct or fix problems. (generally 20% of software maintenance costs)
  2. Perfective – Modifications that enhance or improve the functionality or performance of the software. This includes new user requirements. – costs due to improving or enhancing a software solution to improve overall performance (generally 5% of software maintenance costs)
  3. Adaptive – Software modifications that are required due to environmental changes (eg. upgrade to operating system) – costs due to modifying a software solution to allow it to remain effective in a changing business environment (25% of software maintenance costs)
  4. Preventative – This corrects potential flaws or problems in the software before they become effective.
  5. Enhancements – costs due to continuing innovations (generally 50% or more of software maintenance costs) Same as Perfective ?

What is Support?

 

Support refers to the assistance given to users to address their problems and queries after system implementation.

Key parameters considered while estimating the efforts required.

  • The industry and application type
  • Size of the application
  • Platform Types.
  • Programming language used
  • Effort spent on different maintenance activities
  • Effort spent on different support activities
  • The number and types of defects found during the maintenance period
  • Average time is taken to repair defects
  • Calls to Help Desk
  • Team size

Automated Source Code Analysis

  • The architecture tools and Static Code Analysis in Visual Studio Ultimate help us to visualize the organization, relationships, design patterns and behavior of existing applications

To detect patterns and the general structure of an application at a high level.

  • Generate sequence diagrams from the existing code and get required interfaces for each component
  • Helps to asses the impact of changes

Improve productivity and quality through Automation

  • Automated Live Unit Testing with VS
  • Automatically runs the impacted unit tests in the background as you type and provides real-time feedback

Iterative Waterfall

  • Produces working software early during the lifecycle
  • The focus is on delivering a sprint of work
  • Deliver series of valuable/shippable features/projectsLowrisk
    • Low risks factors as the risks can be identified and resolved during each iteration.
    • if one project goes wrong, it would not impact another project

Flexible

  • More flexible as scope and requirement changes can be implemented at low cost

  • SDLC Models
    • https://www.itproportal.com/2010/07/04/comparison-various-software-development-life-cycle/
    • http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=32B2FE647EC4C6DF095FC1D671C4A24A?doi=10.1.1.667.9896&rep=rep1&type=pdf
    • http://www.agilistapm.com/differences-between-waterfall-iterative-waterfall-scrum-and-lean-software-development-in-pictures/
    • https://www.mountaingoatsoftware.com/blog/an-iterative-waterfall-isnt-agile

 

  • Requirement Elicitation
  • The term elicitation is used in books and research to raise the fact that good requirements cannot just be collected from the customer, as would be indicated by the name requirements gathering. Requirements elicitation is non-trivial because you can never be sure you get all requirements from the user and customer by just asking them what the system should do OR NOT do (for Safety and Reliability). Requirements elicitation practices include interviews, questionnaires, user observation, workshops, brainstorminguse cases, role playing and prototyping

Reverse analysis the source code

  • Visual Studio Architecture Tooling Guide Scenarios https://blogs.msdn.microsoft.com/visualstudioalmrangers/2015/04/22/library-of-tooling-and-guidance-solutions-aka-msvsarsolutions/
  • https://vsardata.blob.core.windows.net/projects/Visual%20Studio%20Architecture%20Tooling%20Guide%20-%20Scenarios.pdf 
Questions / Metrics

  1. Size of each application or module
Application Number of Modules Number of

Screens

 

Number of  Scheduled Batches Number of  Integrations to External applications

The number and types of defects found in a year

Classification Priority No of issues found
Standard Critical (P1)
High (P2)
Medium (P3)
Low (P4)

List of different .NET languages, Databases used with the applications.

Technology / Languages Number of applications
C#
VB. NET
SQL Server
Oracle
MySQL
NoSQL

List of different .NET frameworks used with the applications.

Technology / Languages Number of applications
ASP.NET – Web Forms
ASP.NET – MVC
WinForms
WPF
WebAPI
WCF
SingalR
Entity Framework
NHibernate
Angular
Any other technologies
 

Third-party applications or packages integrated with the applications

Third Party integrations Number of applications
CRM (Siebel, Vantive, Remedy, SharePoint, Documentum etc.)
BI / OLAP / DW Tools

(ETL, Data Stage, Sagent, Informatica,

SAS, Ab Initio)

ERP Skills (Peoplesoft, SAP,

Oracle Applications etc.)

 

Software development life cycle models used

SDLC Number of applications Number of releases in a year
Waterfall
Iterative Waterfall
Agile
Any other SDLC methods

Type of Integration and deployment methods used (to estimate the efforts to deliver the build to different environments

Integration and Deployment Number of applications
CI/CD
Automated deployments only
Manual Integration and deployment

Availability of the documents in English –  Architecture documents, HLD, LLD, User guides, deployment documents

References

  1. https://files.ifi.uzh.ch/rerg/arvo/courses/seminar_ws02/reports/Seminar_9.pdf
  2. https://gupea.ub.gu.se/bitstream/2077/10553/1/gupea_2077_10553_1.pdf
  3. https://www.slideshare.net/anandsubramaniam/project-metrics-measures
  4. http://isbsg.org/maintenance-support/

SPA -Part 1:JavaScript to Angular

Introduction

This article is a collection of notes and references from other web sites for the self study of Single Page Applications and Angular. The list of source web sites referred are mentioned in the “POINTS OF INTEREST” section of this article.

Background

  • Single-Page Applications (SPAs) are Web apps that load a single HTML page and dynamically update that page as the user interacts with the app.
  • SPAs use AJAX and HTML5 to create fluid and responsive Web apps, without constant page reloads. However, this means much of the work happens on the client side, in JavaScriptThe Traditional Page Lifecycle vs. the SPA Lifecycle
  • In a traditional Web app, every time the app calls the server, the server renders a new HTML page. This triggers a page refresh in the browser.
  • An SPA renders only one HTML page from the server, when the user starts the app. Along with that one HTML page, the server sends an application engine to the client. The engine controls the entire application including processing, input, output, painting, and loading of the HTML pages.
  • In an SPA, after the first page loads, all interaction with the server happens through AJAX calls. These AJAX calls return data—not markup—usually in JSON format. The app uses the JSON data to update the page dynamically, without reloading the page.
  • Benefits
    • One benefit of SPAs is obvious: Applications are more fluid and responsive, without the jarring effect of reloading and re-rendering the page.
    • Typically, 90–95 percent of the application code runs in the browser; the rest works in the server when the user needs new data or must perform secured operations such as authentication. Because dependency on the server is mostly removed, an SPA autoscales in the Angular 2 environment: No matter how many users access the server simultaneously, 90–95 percent of the time the app’s performance is never impacted.
    • Sending the app data as JSON creates a separation between the presentation (HTML markup) and application logic (AJAX requests plus JSON responses).
    • In a pure SPA, all UI interaction occurs on the client side, through JavaScript and CSS. After the initial page load, the server acts purely as a service layer.

ECMAScript Vs TypeScript

ECMAScript (or ES) is a trademarked scripting-language specification standardized by Ecma International in ECMA-262 and ISO/IEC 16262.

  • It was created to standardize JavaScript, so as to foster multiple independent implementations. ECMAScript is the language, whereas JavaScript, JScript, and even ActionScript 3 are called “dialects”.
  • ES5 is the JavaScript you know and use in the browser today. ECMAScript version 5 was finished in December 2009,  the latest versions of all major browsers (Chrome, Safari, Firefox, and IE)  have implemented version 5. So ES5 does not require a build step (transpilers) to transform it into something that will run in today’s browsers.
  • Coders commonly use ECMAScript for client-side scripting on the World Wide Web, and it is increasingly being used for writing server applications and services using Node.js.
  • TypeScript is a strongly typed, object oriented, compiled language. It was designed by Anders Hejlsberg (designer of C#) at Microsoft. TypeScript is both a language and a set of tools. TypeScript is a typed superset of JavaScript compiled to JavaScript. In other words, TypeScript is JavaScript plus some additional features.

  • As data types are introduced in Typescript below concepts are applicable
    • Variable declaration with datatypes
    • Type conversion/casting
    • Function overloading
    • Generics
  • As OOPs are inbuilt in Typescript below concepts are applicable
    • Class declarations with private, public, protected, static members
    • Constructor
    • Inheritence, Overriding, Interfaces, this and base operators

OOPs in ECMA Vs TypeScript

  • An object is an unordered list of name-value pairs. Each item in the list can be a property or methods.
  • JavaScript does not have classes. The classes in ES2015 are just a cleaned up syntax for setting up prototype inheritance between objects.
  • ECMA5 has a prototype-based inheritance mechanism: Every JavaScript function has a prototype property, and you attach properties and methods on this prototype property when you want to implement inheritance (to make those methods and properties available to instances of that function).This prototype property is not enumerable; that is,only one object can be assigned.
  • constructor is a function used for initializing new objects, and you use the new keyword to call the constructor.

In ES5 and earlier, constructor functions defined “classes” like this:

function Person(firstName, lastName) {
  this.firstName = firstName;
  this.lastName = lastName;
}
var person = new Person("Bob", "Smith");

ES2015 introduces a new syntax using the class keyword:

// the name of the ES5 constructor
// function is name of the ES2015 class
class Person {

  // observe there is no "function" keyword
  // also, the word "constructor" is used, not "Person"
  constructor(firstName, lastName) {

    // this represents the new object being
    // created and initialized
    this.firstName = firstName;
    this.lastName = lastName;

  }
} 
var person = new Person("Bob", "Smith");
// TypeScript

class Person {
  
  firstName: string;
  lastName: string; 
  
  constructor(firstname:string, lastname:string ){
  this.firstName = firstname;
  this.lastName = lastname; 
  } 
}

var person = new Person("Mary", "Smith", 39);

Hello World from TypeScript

<!DOCTYPE html>
<html lang="en">
<head>
    <title>TypeScript HTML App</title>
    <script src="app.js"></script>
</head>
<body>
    <div id="content"></div>
</body>
</html>

//app.ts
class Greeter {
    element: HTMLElement;

    constructor(element: HTMLElement) {
        this.element = element;
        this.element.innerHTML = "Hello World";
    }
}

window.onload = () => {
    var el = document.getElementById('content');
    var greeter = new Greeter(el);
};

//Tranaspiled code
var Greeter = (function () {
    function Greeter(element) {
        this.element = element;
        this.element.innerHTML = "Hello World";
    }
    return Greeter;
})();

window.onload = function () {
    var el = document.getElementById('content');
    var greeter = new Greeter(el);
}

Points of Interest

You can explore more on the objects and OOPs in Javscript in below references.

History

Version 1.0 – 2017  June 21 – Initial