Software Quality Management

Software Engineering Series Part 3

Definition of Quality

• Fitness of use - fidelity to requirements, available, reliable, accurate, speed and ease of use
• Absence of defects

Residual Defect Density

• Single measure of quality - Number of remaining defects per unit functionality
• Measured in two ways - Static RDD and Dynamic RDD
• Static RDD - Open defects per line of code; should interest the developer; Collected in Alpha tests
• Dynamic RDD - Open defects per transaction; detected at runtime; Collected in Beta tests and should interest the customers

Quality attributes

• Availability
• Reliability
• Accuracy
• Speed
• Ease of use

Availability

• How often is the system unavailable for use; either regularly or sporadically
• Planned and Unplanned downtime
• Defined in terms of planned hours of service, like between 7:00 AM to 10:00 PM and maximum allowable unplanned downtime, like not more than 15 minutes per working day.

Reliability

• How often does a system fail to perform a requested function or transaction
• Most system also specify the corrective actions to be taken in case of a failed transactions

Accuracy

• How often does the system give bad or wrong result
• Measure of how nearly correct is any information in the system. For example, the time of arrival of train in MRT station.

Speed/Performance

• How quickly can the system perform a transaction
• There are two aspects to speed - system performance (how fast the system can respond to a request) and ease of use (how easy or fast is the system for the user to make a request)

Ease of use

• How easy is the system to use from the users perspective
• Depends on many things such as system speed and accuracy, intuituveness, user speed and accuracy

Quality Specification

• Initial tasks of Quality management - specify (1) What is users expectation of quality (2) What quality is practically possible in the budget and timeline constraints (3) What is out of the scope
• All quality related specifications are referred in terms of metrics. Each quality attribute is measurable and is quantified and has a threshold value. This threshold value divides the acceptable from the unacceptable quality.
• Another important part of the specification is the mesaurability - how, when and by whom should the quality attribute measurements be taken.
• Finally the specification should lay in concrete terms the action plan - should specify the product components affected, checks or tests to be performed, roles and responsibilities of checkers and testers, actions to be taken in case of failures.

Verification Process

• Objective to prove to our satisfaction and the customer's satisfaction that the project output meets the requirements specification.
• Typically involves two parts - Quality Assurance and Quality Control and the various activities are carried out at several stages of the development phase.

Verification Techniques

• Inspection - Detailed and systematic scanning of the product by a skilled personnel; Generally done for documentation, help files, installation guides, navigation screens and other user centric components
• Reviews - Structured walkthrough of a product by a review team. Review team could be comprised of customers, development representative and perhaps an external expert; generally done for system architecture, high level design and workflow
• Tests - Black and White box testing; Stress test; generally dont for functional components

Verification Planning

• When - What points in life cyles
• What - system, functions, attributes
• Who - developer, customer, auditor
• How - process and technique
• Success criteria
• Follow up action

Final Verification

• Formal acceptance
• Notice of deviation
• Request for corrections
• Approval to continue
• Approval of payment

s

ss

Software Development Lifecycle Processes

Software Engineering Series Part 2

Some Useful links

• http://codebetter.com/blogs/raymond.lewallen/archive/2005/07/13/129114.aspx
• http://en.wikipedia.org/wiki/Category:Software_development_process
• http://en.wikipedia.org/wiki/Waterfall_model

SDLC Process

• Defines specific approach to producing software
• Defines the order of stages involved in software development
• Establishes the entry and exit criteria during stage transition
• It also provides guidance and suggestions regarding the ordering of the major phases of the development cycle and the deliverables that need to come out during each phase
• It provides the bases for WBS and suggests the standards needed by the project.

SDLC Process selection criteria

• Organizational culture (Is quality or cost the driver)
• Nature of the software
• Maturity of the technology being used
• Familiarity with the application and technology
• Any predetermined methodologies
• Project constraints such as resources or timescale

Types of SDLC models

• Waterfall model
• Incremental model
• Evolutionary model (Prototyping model, Spiral model)
• Prototyping model

Waterfall model

• Originally coined by WW Royce
• The development process is represented by a set of phases which must be executed sequentially.
• Delivery of te complete system occues at end with a single milestone.
• Generally the model says that the next phase is executed only when the current phase is completed entirely. It does not allow for going back, however, some modifications to this model allow iterations between phases for error correction.

Advantages of Waterfall model

• Simple, structured, disciplined model and hence easy to work with
• Because the model emphasises on completing the current phase entirely before moving on to the next, any errors are caught right at the beginning and hence is generally cheaper to fix, as opposed to finding issues with earlier stages at later phases. For example, if any design issue is present, it should be caught right at the design phase itself. This is also sometimes called as BDUF - Big Design Up Front approach. This approach is very suitable for stable shrink-wrap kind of software where the requirements are know at the beginning.
• Generally Waterfall model lays a lot of emphasis on documentation of a particular phase before transitioning to the next step. This is a big plus in cases of large employee turnover.
• Generally, the projects should be completed at a faster rate when compared to other models. However, the staff profile needed will be more.

Problems with Waterfall model

• The fact that a phase needs to be completed entirely causes a problem for the Specification Phase. Very rarely are the requirements so clearly spelt out right at the onset. To top that this model does not scale for any changes in requirements.
• Practically it is very difficult to complete a phase entirely at one go. Most of the times, a phase needs to be revisted if not for anything else but corrections.
• Project control becomes difficult because of the lack of feedback in a pure Waterfall model. Also it does not lend well for risk management.
• Customers cannot get any iterations and cant see a working copy till the end.

Incremental model

• Improvement over Waterfall model to cater to multiple phases of release and changing requirements.
• Has an Initial Phase and then has iterations till final version. Each phase is a mini-waterfall process. Implementation of software is released as a series of planned successive versions.
• Each delivered version is itself usable and later versions build up on the functionality and probably quality.

Advantages of Incremental model

• Intermediate releases more helpful to user than the final monolithic release in waterfall model. Also user feedback can improve quality of subsequent releases.
• Testing process is easier because the release is staggered
• Because of multiple releases, the SDLC is more manageable.
• Budgeting, resource allocation etc can also be staggered.
• Easier to deal with in terms of risks

Problems with Incremental model

• Development costs are likely to be higher because of the iterations, however maintenance and enhancements costs are likely to be lower.
• Subsequent releases pose a risk of regression. This may further increase the cost

Evolutionary model

• Planned development of multiple releases; State and expectation of the release itself is not very concrete
• All phases are performed in each release, the release then analysed; and building on the understanding gained; another version is planned.

Advantages of Evolutionary model

• Very useful when requirements are not clear at the beginning
• Very useful when technology is not mature or understood

Problems with Evolutionary model

• Because the requirements are not clear and the approach is more of trial and error in nature, may turn out to be expensive
• Initial software may not be used directly for building later releases as they may be unstable. If such software is really used, then temporary solutions may be embedded in the system and may distort the evolution.
• Very difficult to form contractual arrangements based on this model.
• Users may become impatient with the half-baked releases.

Prototype model

• Prototypes are used in the model to test the feasibility of an idea or a product before more concrete plans are made.
• Prototypes could be used a tool to fine-tune the requirements.
• Prototypes themselves may or may not be used in the actual software construction. If the prototype is not used, it is called Throwaway Prototype model.

Advantages of Prototype model

• Greatly reduces risk
• A great way to understand user requirements and hence can lead to better quality products
• Some times the only choice when dealing with technical design issues
• Can reduce development costs and increase chances of success.

Problems with Prototype model

• If prototypes are reused in the development, there is an excuse for uncontrolled development
• Sometimes throwaway prototypes may increase costs
• If prototypes become the end product, quality could be very poor. In anycase, the risk is always there as the customer does see a working model and may be tempted to use it.

Spiral model

• A mixture of prototype and evolutionary models with a very thick emphasis on risk analysis.
• The radial dimension signifies the cost.
  The angular dimension or the four quadrants of the spiral signify the progress made.
• Typically has four phases which get iterated over and over starting from the base spiral inching up with improvements in each spiral.
• The four phases or quadrants of the spiral are (1) Determine objectives, alternatives and constraints (2) Evaluate alternatives, Resolve Risks, Prototype etc (3) Develop which may involve a complete waterfall (4) Plan for the next iteration

Advantages of Spiral model

• High amount of risk analysis
• Good for mission critical projects

Problems of Spiral model

• Can be costly
• Doesnt work well for smaller projects

Software Engineering Processes

Software Engineering Series Part 1

Good Software System

• Is of good quality - has well defined purpose, meets the business needs, is usable; is reliable, accurate, fast, available
• Is well designed - design is extensible to meet the future change requirements; maintenance is easy

Process Definition

• Process - Ordered set of steps intended to achieve a goal. Another definition is - One or more agents acting in defined roles to carry out the process steps to accomplish the overall process goals. At the end of a step, process artefacts may be created or modified
• Software process documents how software projects are initiated, managed, implemented, concluded and improved

Characteristics of good Software Process

• Clearly defines the deliverables and the product
• Correctly defines the sequence and interrelations of activities needed to produce the software
• Clearly defines the roles and responsibilities
• Has an effective Process control; defines how the activities are to be performed; methodologies, standards, reviews etc

Software Engineering Processes

• Software Development Lifecycle
• Software Process Management
• Software Project Management
• Software Product Management
• Software Quality Management

Issues in managing and Improving Process

• Choosing a Process - need to understand the details of the process and the interaction between the chosen process and methodology chosen. To improve an existing process, the current process needs to be understood, the weakpoints need to be identified, understand how it needs to be improved, implement and measure the improvement
• Process is followed - Ensure that deliverables of each step is produced; Exit criteria for the current step is met; Entry criteria for the next step is met

Uses of Software Process modelling

• Facilitate human understanding and communication
• Support process improvement
• Support process and project management
• Process automation

Perspectives in Process

• Functional - what process elements are being performed; what are the information entities involved
• Behavioural - When and what process elements are being performed; consider timing and sequential issues
• Organisational - When and by whom the process elements are being performed; How entities are transferred
• Informational - What are the entities, their structure and relationships in the organization

SADT - Structured Analysis Design Technique

• Inputs - Things used and transformed by Activity to Output
• Activity - Atomic step of a process
• Output - Things into which inputs are transformed by a process
• Triggers - event or a directive to begin the activity
• Control and Guiding Mechanism - Document or information items that will guide or constrain activities
• Resource Mechanism - how the activities are realized

Definition of Project

• Scope and Objective
• Team of people
• Timeline and budget
• Risks
• Pricess to achieve objective

Objectives of Project Management

• Define Scope, Process and objective of Project
• Process used to achieve the project objectives
• Team/Resources
• Costing and Schedule
• Risks Management
• Project Control
• Quality Management

Project Planning Process

• Define the Project Deliverables
• Identify and evaluate Project Risks
• Determine how to manage Project Risks
• Develop WBS
• Identify Staffing and Resources
• Effort estimate required to complete tasks
• Estimate Project Costs
• Identify Dependencies and establish Schedule

Project Plan Contents

• Intrduction
• Document SDLC
• Project Structure
• Deliverables
• Work Plan - WBS/Resource/Estimate
• Project Schedule
• Project Cost
• Risk Management Plan

Project Planning Guidelines

• Make sure that scope of each level in WBS gets mapped to tangible tasks
• Make sure that all tasks have estimates
• Make sure that no Task at level 1 (Phase) is longer than 1 year
• Only plan the next phase in detail
• Ensure that detailed planning level is no longer than 1 month and the lowest level of task greater than 2 work weeks.

Definition of Risk

• Potential for harm arising out of either a current process or a future event that may harm the software being developed in a negative way (functionality, reliability, usability, performance, schedule, cost)

Risk Management

• Risk Assessment - Identification, Anlysis, Prioritization
• Risk Control - Planning, Resolution, Monitoring

Risk Resolution Techniques

• Contingency Planning
• Accept Risk and live with it
• Avoid Risk - for example by doing something differently, so that the risk is not in the picture at all
• Investigate to understand the risk so that we can resolve the risk after understanding it better
• Transfer to somebody else who can handle the risk

Definition of Quality

• Meeting the agreed requirements
• Zero defects

Quality Acitvities (http://geekswithblogs.net/srkprasad/archive/2004/04/29/4489.aspx)

• Quality Assurance - Preventing defects in deliverables by establishing project quality standards and procedures for the entire SDLC. A set of activities designed to ensure that the development and/or maintenance process is adequate to ensure a system will meet its objectives. In other words, Quality Assurance makes sure you are doing the right things, the right way. It is more on the Process end, rather than on the Product end.
• Quality Control - Inspection of deliverables for defects, reviews, testing, walk-thrroughs etc. Quality Control makes sure the results of what you've done are what you expected.
• http://c2.com/cgi/wiki?QualityAssuranceIsNotQualityControl

Quality Plan

• Standards and Guidelines
• Techniques and Tools
• Software Configuration Management
• Test Strategy
• Project Procedures
• Reviews
• Approval Process
• Change Management
• Progress Reporting

Purpose of Project Control

• To ensure that project runtime runs along the planned activities as listed in the Project Plan.
• Ensure that the project completes successfully according to the scope and quality specification laid out in the Project plans.

Activities in Project Control

• Day to day Project Control, monitoring and reporting
• Tasking Project Staff
• People Leadership
• Technical Leadership
• Vendor Management
• Quality Management
• Risk Resolution
• Change Control

OMG Specification Process

In OMG Specification Adoption process(http://www.omg.org/gettingstarted/processintro.htm), there are typically two types of actors

1. Voters (http://www.omg.org/gettingstarted/process3-Votes.htm)
2. Submitters

All submitters are voters, but not the other way.

The voters themselves fall in many groups -

1. Technical Committee (Platform and Domain)
2. Architecture Board
3. Task Force
4. Board of Directors

The Specification Adoption process and the adopted specification goes through the following life cycle -

1. Creation
2. Maintenance

OMG standard creation goes through the following phases

1. RFI (Request for Information) Process
2. RFP (Request for Proposal) Process
3. Finalization Process

Request for Information Process
This is an optional step. Typically in this step the Technical committee forms a Task Force and the Task Force issues a "Request for Information" to the industry to collect information. This process involves the following steps -

1. TF creates RFI and votes for acceptance before submitting to its Technical Committee
2. Technical Committee votes the RFI for issuance
3. Technical Committee issues the RFI
4. Submitters can then respond to the RFI. Submitters present their submissions to the TF and may also demonstrate if they have anything worthwhile
5. The TF after their meetings with RFI submitters can then use the information however they want in the forthcoming RFP.

As stated earlier, RFI is an optional step and is not mandatory for an RFP. Since RFP is itself the Requirements specification for the forthcoming specification, RFI may be considered a kind of information gathering.

Request for Proposal Process

RFPs are actually the requirements documentation for the specification in question. The task force formed by the Technical committee is responsible for creation of the RFP. They may take the help of the RFI step to make concrete the requirements, if the requirements are not very clear. RFP, along with he requirements also specifies the time line of action that is to be taken. Typically, it lists the LOI deadline (Letter of Intent) and Submission Date. So, it consists of the following steps

1. TF writes and votes to accept it for forwarding to the Technical Committee
2. The Architecture Board also votes on the created RFP
3. The parent TC of the TF votes to issue the RFP. The RFP by default binds the timeline for Letter of Intent and Initial Submission Date.
4. Companies interested in submissting for the RFP submit their LOI before the deadline.
5. Then, by the Initial Submission Date, they submit their proposals. If they need more time for submission, a revised submission date can be obtained.
6. The submission date typically falls about 3 weeks before an OMG technical meeting. OMG members then read the submissions and if they dont like make comments. In most cases, the submitter needs to get back with a revised submission.
7. When the submission is ready for acceptance, the TF votes to recommend forwarding to the TC.
8. AB then votes.
9. TC then votes to recommend to the BOD.
10. BOD then votes to make the submission "OMG Adopted Specification".

Once the specification gets the BOD nod, though the specification gets a n OMG adopted specification status, it still does not get a release number. This is because, typically the adopted specification has quite a few inconsistencies and bugs that get resolved in later versions. In aknowledgement of this fact, OMG differentiates between Adopted Specification and Available Specification. An Available Specification is typically formed by a Finalization Task Force after the Adopted Specification is released. The following happen from the Adoption stages to making the specification available -

1. On successful creation of an Adopted Specification, the TC forms a Finalization Task Force (FTF) which makes changes to the Adopted Specification based on the issues encountered and reported and creates a first revision of the Adopted Specification.
2. The issues when encountered get reported as "Specification Issues" to OMG, on which the FTF acts.
3. This revision goes through the same voting process as the Adopted Specification and the result is the Available Specification. This available specification may be further edited to produce the Formal Specification.

Specification Maintenance
Once a formal document is created, immediately the TC creates Revision Task Force RTF to cater to any changes or bug fixes needed and also defines two timelines - Comment Deadline and Report Deadline. The Revision task force collects and acts on the Specification Issues submitted and through the voting process as described earlier makes revisions to the specification and releases them. On release, another RTF is automatically created. Following are the steps that are followed in this process

1. On successful Formal document creation, the TC forms a RTF and along with this specifies the Comment deadline and Report deadline.
2. Users and members can then report issues against the formal document as Specification Issues which get logged in a database. Typically, the issues can be categorized as either errors, ambiguities or enhancement requests.
3. RTF acts on the errors and ambiguities recieved before the Comment deadline to work on to produce a document revision. RTF resolves and gets data regarding the issues using emails.
4. In anycase, the RTF needs to have all the issues voted before the Report Deadline. The report deadline indicates the "transactionable" time for the RTF and is considered not contactable after this time. RTF also need to vote the revised to be forwarded to the TC before the report timeline.
5. The revised document (also called report document) is then forwarded to AB and then TC and then BOD to voting.
6. Once BOD approves the document, the changes are incorporated into the original version and new version is created. After this version is created the RTF process continue

Types of Documents
The following types of documents are published. The type really depends on the state of the process at which it was created -

1. Final Adopted Specification - This is the formal adopted specification. The FTF task force is not yet created. These documents are prefixed with "subgroup/". For example subgroup/06-01-09.pdf
2. Proposed Available Specification - This is the FTF report which has been recommended to the TC for approval. The voting process is underway. These documents are prefixed with "dtc/ or ptc/". For example ptc/06-01-09.pdf
3. Available Specification - This is the adopted version of the FTF report.
4. Version 1.0 - The formal document after editorial changes on the FTF report. These documents are prefixed with "formal/". For example formal/06-01-09.pdf
5. Proposed Available Revision - RTF report completed; voting underway. These documents are prefixed with "dtc/ or ptc/". For example ptc/06-01-09.pdf
6. Available Revision - Adopted RTF revision
7. Version x.y - formal revision publication.

zz The

XML Basics

XML Series Part 1

Introduction

Some definitions

XML - Extensible Markup Language; subset of SGML (Standard Generalized ML); Meta-language to create other markup languages.

Markup - Set of codes or tags added to content of document in order to indicate its meaning or representation. Non-standardized markup languages such as RTF have many disadvantages – (1) Proprietary and specific to particular applications (2) Difficult to read and manage (3) Poor problem-domain semantics – more based on presentation rather than the data itselfSGML was the original meta-language created based on markups. SGML gave the rules on how the markups should be used. Based on these rules, the user or the application could create custom markup language for specific problem domain. HTML was an application of SGML. However, because of SGML’s complexity, it failed to be accepted completely. XML was then created using a subset of SGML features. In effect XML could capture 80% of SGML power with mere 20% of its complexity.

XML suite of standards – XML is complemented by many other related standards to enrich with features such as linking, transformation and advanced data modeling – called the core or fundamental specifications. Some of the key words here are XML Info seet, DOM, SAX, XML 1.0, Namespace, Xpath, Xpointer, Xlink, XSLT, XSL, XML Schema, DTD.

XML Document

XML Element – Basic content unit in XML; delimited by tags; three types of elements –

• elements containing character data
• elements containing other elements
• elements containing character data and other elements called mixed-content element

If the elements are nested correctly, then it is said to be well-formed

Logical Structure

• Recommended and Optional Prolog - contains XML declaration and optional DTD
• Root Element - Also called Document element which contains all other markups and charecter data
• Not recommended and Optional Epilog - contains comments and other non element markups

Prolog – option for the first line to declare the version of XML being used and the character encoding of the document – for example if a document was written in XML 1.0 version using UTF-8 encoding, then the XML document could have an XML declaration as -

<?xml version=”1.0”?>

Physical structure

Made out of pieces of text composed of character data and markup. The following are instances of markups – start, end and empty tags, attributes, comments, PI – processing instructions, CDATA section delimiters, Entity references, Character references and DTD. Everything else in the document, which is not the above, is considered character data. For example in

;
<movie>
<title> L.A.Confidential </title>
</movie>