Concurrent Programming

Introduction

Concurrent programs take into account the execution of a program faster in real time situations so that proper synchronization of activities are made and the user is at ease (Andrews, 1983).

The first part of the paper discusses the concurrent programs and its characteristics, its very difference from other programs and the development strategy followed.

The second part concentrates on the project management techniques and the various people and documents involved in the process of making a team successful in their development objectives.

The second part is concerned with the verification and validation of the programs which is utmost essential for getting both the requirements and workability correct in all senses.

Concurrent programs

  Concurrent programs: Definition and concepts

Concurrent programs are linked with the parallel execution of a single program. It enhances speed of execution and contemplates the very use of I/O and CPU resources at all times (Ben-Ari, 1982). It also defines actions that can be performed simultaneously.

 Difference from distributed and parallel programs

Parallel programs are concurrent programs that are designed for execution in parallel hardware.

A distributed program is one which encompasses both concurrent and parallel programs designed for execution on a network of autonomous processors that do not share main memory (Brinch, 1977).

  Interaction of processes

The nature of concurrent programs involves the usage of processes. It happens due to two reasons:

• Processes often compete for shared resources which can be physical devices
• Inter-process communication for message and data passing

In the above two cases it gets utmost necessary to get synchronized in their execution pattern either to safeguard against conflict in acquiring resources, or to make contact, when exchanging data.

Processes perform interaction among themselves and with its environment two ways, either through shared variables, or by message passing among processes. Processor power and memory are also shared or held shared for facilitating the processes to function correctly.

Resource management is an effective technique for synchronization of processes and their interaction. The process seeks permission for the resource it desires to access and releases it after the job is performed so that it can be used by other processes (Lamport, 1989).

Properties. The properties are the various factors that it possesses for effective management and correctness. The safety properties emphasize the program behavior and their nature. The mutual exclusion feature makes the processes quite exclusive to access the critical region. The deadlock prevention and the partial correctness stresses on the event the process is said to execute in a generous manner. Likeness characteristics state what a program must do and include an array of variables like fairness, reliable communication and total correctness.

Execution. The execution of concurrent programs is mainly done on multiple processors either sharing the same memory or having different memory. It is often executed in a distributed environment

The patterns of execution start with a single process and break up into child processes to divide its execution tasks and jobs so that more than one process is able to execute at a given point of time. It spawns further processes and lastly joins all of them to finish the task so as to release memory and space resources.

Once a process is generated, it takes several states in its execution phases and is often swapped for better handling of other processes in memory.

Concurrent programs: Development methods

The life cycle of development would be taken up for the benefit and ease of the development of concurrent programming (Scacchi, 1987). The development methods for concurrent programs are as below:

• Requirements analysis: The primary analysis of the system is essential for enveloping all the business data and information requirements to map all processes in the organization (Hoffer, 2002). It is done so that no data is left out and there is 100% coverage of the business requirements. The requirements of this stage demand enough expertise and skill to effectively understand and capitalize on information so that information is captured to its full swing.
• Systems analysis and Design: Once all the requirements are collected successfully they are analyzed to their importance and framed into defined design models such as DFD, E-R diagram and others so that their modeling is successfully transformed into a working system (Navathe, 2003). The entire design reflects the working of the organizational processes and their penetrations with external forces. The capabilities of this stage demands business modeling methods and strategies for developing a suitable data flow diagram to correctly figure out the process.
• Systems coding: This is the actual step where the business requirements are actually implemented and taken care to be given a representation. The impact of this stage would result in greater understanding of the business methods and good communication skills with the client. This stage creates an impact to make a difference to code the system to exact requirements mapped in the planning stages.
• Systems implementation: Successful implementation of the system is essential for the system to facilitate working and for the users to take full advantage of the system (Laudon, 2002). The impact of this stage is quite large as improper implementation strategies may affect the working of the organization and processing capabilities.

Concurrent programs: Design methods

The primary methods for designing of the concurrent system are as follows:

• Finite state machines (FSM): It is primarily used to model the behavioral nature of the process. Concurrent systems would be the ones which can be termed as interacting FSMs. It is also defined as a set of states and transitions among them.
• Data flow diagrams: It is a graph showing data transformations and repositories and the interaction among them.
• UML class diagrams: The components can be framed into objects and classes to represent their properties and behavior and the model can be constructed for depicting interaction among them.

Concurrent programs: Coding

The coding view of the processes in the concurrent programs can be achieved through various means. The following are the ones:

• Shared variable: The interaction of the processes using shared variable is possible to enforce mutual exclusion and safe access to critical section (Dijkstra, 2002).
• Status variables: Access to the critical region can be done using status bits to detect whether any process is occupying the area. It is a check mechanism.
• Semaphore: It is a variable to enforce synchronization between the processes. It takes into account wait and signal functions for telling the process to wait for the signal to access the critical region (Galvin, 2002).

Program 1: Illustrating use of semaphores to control inter-communicating processes.

Message passing: It is a model of communication between the processes. Information is exchanged through an inter-process-communication facility provided by the operating system. Prior to it a connection is opened, the name of the two communicating processes is known to the operating system. One of the processes call the wait function for connection call is usually is the client and the connecting process is the server process. They exchange message by read and write system call and the close connection terminates the communication.

Monitors: It is used to batch the similar resource in the same program block. A monitor provides a set of procedures through which operations on shared data are performed. The execution of one procedure by any process causes all other processes attempting entry to the monitor to be delayed until the first process has finished or has been suspended (Hoare, 1974).

 Project management techniques

Project management objects and tools

Hoffer mentions that the various project management tools are the essentials that are maintained form the project concept stage to project finish and implementation.

• Project task order (PTO) is a document with four basic sections: Introduction, Statement of Work, Project Organization, and Project Costs. The Introduction summarizes the project by documenting the background, business need, benefits, audience, risk assessment, definitions, and references for the project. The Statement of Work documents the task descriptions, deliverables, dependencies, and schedule for the project. The Project Organization documents project responsibilities, the staffing plan, and resource requirements.
• Project change order: A document that describes proposed changes to a project. The document itemizes changes in schedule and cost or describes changes in functional scope.
• Project status report: A document that describes the status of a project by documenting the original and current schedule dates, the status of deliverable, and a narrative describing any deviations from the plan.
• Software development project plan (SDPP): A plan that defines the development approach for a project, describing the tasks, task sequence, task durations, task dependencies, milestones, and deliverables, in greater detail than the Project Task Order.

Roles and responsibilities

The following are the various roles and responsibilities that require being there in place for the effective completion and finish of the program.

• ITSC Steering Committee (STCO): They are responsible for the follow: • Reviews and approves all ITSC software development PTOs, in accordance with the criteria in Article VI of the ITSC Charter. • Reviews progress of all ITSC software development projects. • Responds to modifications of the PTO due to Project Change Orders or other events. • Monitors corrective action where necessary to meet project goals.
• ITSC Project Manager (IPM): They perform the following: • Controls day-to-day and strategic issues on the project.  Communicates with the ITSC Chief Technologist, ITSC Software Council, and ITSC Executive Director. Initiates corrective actions when necessary.  Chief point of contact with the Client Project Manager. Responsible for producing the initial PTO. Responsible for producing the Project Status Report (PSR) monthly. Develops and maintains the Software Development Project Plan. Manages all Project Change Orders for the project. Modifies the PTO as necessary. Meets, as necessary, with State Grant Manager and Federal Grant Manager.
• ITSC Chief Technologist (ICT): They function for the following: Provides support, oversight, and technical guidance to the ITSC Project Manager. Tracks quality issues, costs and work scope, timeliness, project budget, plans review meetings; reviews test plans and configuration management procedures. Monitors corrective actions when necessary. Heads the ITSC Software Council. Keeps ITSC Executive Director informed of project issues and status.
• ITSC Executive Director (IED): The responsibilities are as follows: Provides management and guidance to the ITSC Project Manager, ITSC Chief Technologist and the ITSC Software Council. Resolve issues that cannot be handled by the ITSC Chief Technologist and ITSC Project Manager. As part of the customer satisfaction process, midway through the project calls the Client Project Manager and discusses the project status. Makes a record of the call for presentation to the ITSC Steering Committee. Survery Client Project Manager satisfaction at the end of the project.

 Project definition

The Project Task Order (PTO) is a document with four basic sections: Introduction, Statement of Work, Project Organization, and Project Costs. The Introduction summarizes the project by documenting the background, business need, benefits, audience, risk assessment, definitions, and references for the project. The Statement of Work documents the task descriptions, deliverables, dependencies, and schedule for the project. The Project Organization documents project responsibilities, the staffing plan, and resource requirements.

The ITSC Project Manager works with the Client Project Manager to gain a detailed understanding of the services and products desired by the client. In the Statement of Work, the ITSC Project Manager documents the tasks and deliverable products for the project in sufficient detail to accurately estimate the costs and schedule. The project schedule in the PTO shows the work period for all tasks and a milestone for each deliverable.

The ITSC Project Manager and the Client Project Manager select the types of intermediate and final deliverable products for the project. The development of such products will be consistent with the ITSC software development approach to ensure success in meeting client needs. If judged to be prerequisites, these activities would have to have been completed by the client agency before the software development begins, or else be preformed by the ITSC or others before the software development begins. The exact extent and scope of any deliverable included in any software development PTO must be described and agreed upon with the Client Project Manager before PTO acceptance.

For each software development PTO, the ITSC Project Manager must define a task to develop an SDPP. The SDPP shows the activities and interactions that have to be performed effectively and timely for the project to succeed.

The ITSC Project Manager uses the SDPP to conduct the project. Its level of detail will be appropriate to the scale and complexity of the software development effort. The SDPP must be consistent with the PTO schedule, task descriptions, and milestone/deliverable descriptions.

The areas where the project may face risk in terms of uncertainty in ultimate scope and time or resources to complete are analyzed in the Risk Assessment section of the PTO. This section also includes the methods chosen to mitigate and manage those inherent risks. When appropriate the PTO will state that costs and schedule estimates are expected to be re-examined at key points within the project before agreeing to move to the next task. The PTO must also contain information about the terms and condition of the conduct of the work to assure that the project runs smoothly and issues can be resolved efficiently if and when they occur.

The ITSC Project Manager submits the draft PTO for review to the ITSC Software Council. The ITSC Project Manager responds to their comments and guidance. After the ITSC Software Council reviews the PTO, the ITSC Executive Director and the ITSC Chief Technologist review it again before it is sent as a draft to the Client Project Manager for client review. The ITSC Software Council, ITSC Chief Technologist, and ITSC Executive Director review any Client Project Manager comment and changes to ensure that changes from the Client Project Manager have not changed the risk and quality factors for the project. The ITSC Executive Director, the State Grant Manager, and (for Separately Funded projects) the Client Agency Executive then sign the PTO.

Once signed, the PTO is sent to the ITSC Steering Committee for review and acceptance. Once the PTO is finally approved, a Project Activities Repository is established with the PTO as the first entry. The Project Activities Repository is an officially controlled set of PTOs, PSRs, and other relevant material that documents the contractual history, and status of an ITSC project.

Project oversight

These constitute a series of activities that provide visibility into the project status.

Planning: For each software development project, the ITSC Project Manager produces an SDPP. The SDPP includes activities and responsibilities both for the ITSC and the client’s agency. In simpler projects, the SDPP should have been essentially laid out during the PTO development process, thus requiring minimal extra effort. For more complex projects, the SDPP may include a sub-schedule of technical demonstrations, walkthroughs, and reviews that may be needed to provide oversight and quality assurance.

The SDPP should be compatible with or take direct advantage of software management and development tools, as appropriate.

The ITSC Executive Director, the ITSC Software Council, and the Client Project Manager review and approve the SDPP and agreed to abide by its activities and schedule. Following approval of the SDPP, the ITSC Project Manager manages the project day-to-day using the SDPP in concert with the current PTO. The ITSC Project Manager will conduct development team meeting(s) to communicate the project plan documented in the SDPP. Any disagreements on interpreting the SDPP, subsequent to its approval, must be resolved through the change process described in the following section.

Review: On a weekly basis, the ITSC Chief Technologist will review the status of each software development project with the ITSC Project Manager and determine what actions, if any, should be taken. The ITSC Chief Technologist will report any information from these interactions to the ITSC Executive Director, and State Grant Manager during a weekly deliverable status meeting for all ITSC deliverables.

The ITSC Project Manager and the ITSC Chief Technologist will discuss any required corrective actions necessary and present the approaches to the Executive Director.

On a monthly basis, the ITSC Chief Technologist will review each software development projects with the ITSC Project Manager, any necessary project staff, the ITSC Executive Director, and the State Grant Manager. For small and less complex software projects, the monthly review meeting may include multiple projects, as deemed appropriate by the ITSC Executive Director, ITSC Chief Technologist, and the ITSC Project Manager.

On a monthly basis, the State Grant Manager and Federal Grant Manager will review the Project Activities Repository for each project with the ITSC Executive Director, ITSC Chief Technologist, ITSC Project Manager, and ITSC project staff, as necessary. Revisions from the review meeting will be incorporated into the next PSR. As required, the ITSC Executive Director, ITSC Chief Technologist and State Grant Manager can elect to have reviews more frequently than monthly.

Reporting: The Project Status Report (PSR) is a document with two basic sections: Project Overview and Project Narrative. The Project Overview summarizes the project’s status by documenting the Schedule Status (both the original and current plans), Deliverable Status, and Budget Status. The Project Narrative documents any variations between the current plan and the original. The PSR is designed to reflect any changes to the project that affects its outcomes, timing or costs.

The ITSC Project Manager will prepare or revise the PSR for each ITSC project. The ITSC Chief Technologist and the ITSC Executive Director will integrate, review, and approve the PSRs. On approval of a PSR, it is added to the Project Activities Repository for that project.

The State Grant Manager (SGM) and Federal Grant Manager (FGM) will report on overall ITSC project status at each quarterly ITSC Steering Committee meeting.

In summary, the Federal Grant Manager and State Grant Manager are provided necessary management visibility through the Project Activities Repository and the monthly review meetings. The ITSC Steering Committee is kept informed through access to the Project Activities Repository, as well as the summary of project status provided each quarter by the Federal Grant Manager and State Grant Manager.

Project control

During the course of a project, circumstances evolve beyond the understanding of the project partners at the beginning of the project. These circumstances may force changes in the project. A change is a modification to the project that impacts the schedule, cost, need for additional resources, or deliverables originally specified and approved for the project. Either the Client Project Manager or the ITSC Project Manager may initiate a change. All project change requests for ITSC software development projects are accomplished using either a Project Change Order (PCO) or a modified PTO.

Two general guidelines govern ITSC project execution. Billable work will not:

• Begin or continue, without funding approved by the ITSC Steering Committee, or
• Continue past the current project end date without approval of the ITSC Steering Committee.

A Project Change Order is a document with three basic sections: Project Identification, Project Changes, and Project Approval. The Project Identification documents the project’s name, number, and version. The Project Changes documents the details of the change(s) proposed for the project. The Project Approval identifies the ITSC Project Manager, and Client Project Manager and provides space for approval and dates.

The ITSC Executive Director will decide whether a proposed project change is large and complex enough that it is necessary to produce a modified PTO, rather than a Project Change Order. A modified PTO is developed using the same techniques and procedures as the original PTO.

The ITSC Project Manager reviews the project change request to determine the feasibility and impact of the change proposed. The ITSC Project Manager and the Client Program Manager negotiate for concurrence on the proposed change and its impact. When they agree, the ITSC Project Manager and the Client Project Manager approve the project change request. If a project change request cannot be satisfactorily resolved between the ITSC Project Manager and the Client Project Manager, then a notification will be sent to the ITSC Executive Director, the State Grant Manager, the Federal Grant Manager, the ITSC Steering Committee, the Client Project Manager, and any other officially required client representative. These parties will negotiate a resolution as soon as possible to avoid funding or schedule complications.

The State Grant Manager and the Federal Grant Manager review and approve Project Change Orders or modified PTOs. The State Grant Manager and Federal Grant Manager decide whether the ITSC Steering Committee needs to review and approve a modified PTO. Once the Project Change Order or the modified PTO is approved, it is added to the Project Activities Repository. Any Project Change Order generated, received, or discussed by the ITSC and the Client Project Manager will be reported in the next appropriate PSR.

The State Grant Manager and the Federal Grant Manager must be notified by the PSR, and must approve that extension before that date arrives. The State Grant manger and the Federal Grant Manager, as they judge appropriate, will involve the ITSC Steering Committee.

An approved Project Change Order is added to the Project Activities Repository and is reflected in the next PSR.

Development lifecycle documents

They are as follows:

Business Modeling:

• Assessment of Current Operations: A document that describes the operations that are currently performed within a client’s agency for a specified business area. Delivered To: Client Project Manager (possibly written by client) Intended For: Program Staff.
• Business Process Reengineering Model: A document that describes the “as-is” or “to-be” model of the client’s business process. The document may optionally include an assessment of the current system, a description and prioritization of candidate areas for process improvement, and a description of the new or changed processes or workflows. Delivered To: Client Project Manager (possibly written by client) Intended For: Management, Program Staff and IT Operational Staff.
• Assessment of Current Hardware and Software Architecture: A document that describes the current hardware and software architecture in use within the client’s agency. If applicable, it may include a description of network and telecommunications infrastructure. Delivered To: Client Project Manager (possibly written by client) Intended For: IT Operational Staff.
• Information Technology Strategic Plan: A document that describes the “as-is” or “to-be” hardware and software architecture for the client’s agency. The document may optionally include an assessment of the technology needs or the client’s agency, a description and prioritization of candidate areas for architectural improvement, and a description of the new or changed architecture. Delivered To: Client Project Manager (possibly written by client) Intended For: IT Operational Staff.
• Concept of Operations: A description of existing or new systems and processes. It may include a System Requirements Document or a High Level Software and Hardware Architecture. Delivered To: Client Project Manager (possibly written by client) Intended For: Management, Program Staff and IT Operational Staff.

 Requirements:

• Requirements Document: A document that defines the necessary functionality and other attributes (e.g., performance, security, quality) to be included in the completed system. This document may use one or more of a variety of methods to describe the system functions and attributes, such as: • An English specification, which may include ‘shall statements’, ‘use cases’ or other textual representations. • The Structured Analysis methodology, which includes a graphical model of the system, a logical description of all system data, and a specification of all system functions. • The Unified Modeling Language, which includes graphical models of the system, its data, and its behavior, as well as a specification of all system functions. Delivered To: Client Program Manager Intended For: IT Development Staff.
• Design Document: A document that defines the system architecture and design and may include descriptions of the system components (hardware and software) and their interfaces, design decisions and their implications, operational and development environment configurations, database schema (data entities and relationships), data elements, data usage, data security, data integrity, and data lifecycles. The document may document the database “logical” structure, the “physical” structure, or both. Delivered To: Client Program Manager Intended For: IT Development Staff.
• Architectural Design Document: A document that defines the system architecture and design and may include descriptions of the system components (hardware and software) and their interfaces, design decisions and their implications, and operational and development environment configurations. Depending on the size and complexity of the system, this document may be published separately or as part of the Design Document. Delivered To: Client Program Manager Intended For: IT Development Staff.
• Database Design Document: A document that defines the structure of the database and may include descriptions of the database schema (data entities and relationships), data elements, data usage, data security, data integrity, and data lifecycles. The document may describe the database “logical” structure, the “physical” structure, or both. Depending on the complexity of the system and its database, this document may be published separately or as part of the Design Document. Delivered To: Client Program Manager Intended For: IT Database Staff.

Implementation:

• Application Software: Any software executable, source code, administrative script, or ancillary file used to generate or operate the system. Delivered To: Client Program Manager Intended For: IT Development Staff.
• Hardware Platform(s): The hardware that is in physical possession at the ITSC, which were purchased either by the ITSC or the client using client funds. Delivered To: Client Program Manager Intended For: IT Operational Staff.
• Licensed Software: Any commercial-off-the-shelf (COTS) software and licenses, which were purchased either by the ITSC or the client using client funds. Delivered To: Client Program Manager Intended For: IT Development Staff.
• Test Plan: A document that describes the purpose, scope, and methodology for testing the system. The document may include plans for any or all of Unit, Integration, System, or Acceptance tests. Depending on the size and complexity of the system, the document may discuss the structure of (and dependencies between) tests, the roles and responsibilities various testers will assume, test descriptions, test data requirements, test cases, test scripts, how tests will be performed, expected test results, the test environment, what testing tools will be used, and how tests are traceable to the requirements of the system. Delivered To: Internal, Client Program Manager (Optional) Intended For: IT Testing Staff.
• Deployment Plan: A document that documents the steps necessary to install, operate, and maintain the developed system, including the task descriptions, task sequence, milestones, and deliverable, both for the ITSC and the client. Delivered To: Internal, Client Program Manager Intended For: IT Operational Staff.
• Operation and Management Plan: A document that describes the recommended day-to-day operational steps and procedures, necessary to support the software application. The document may include the use of any special utilities developed for, or provided with, the application. Delivered To: Client Program Manager Intended For: IT Operational Staff.
• User Documentation: A document that describes the application software functionality as it relates to user roles defined by the customer. Examples of user roles include: data entry clerk, supervisor, and administrator. Delivered To: Client Program Manager Intended For: End Users.
• System Documentation: A document that defines application maintenance procedures, scripts, and data necessary to operate the system. Together with in-line source code documentation and on-line help descriptions, this document provides the information necessary for a software developer to modify and maintain the software. Depending on the size and complexity of the system, this document may be published separately or as part of the Design Document. Delivered To: Client Program Manager Intended For: IT Development Staff.
• Training Materials: A document containing materials from which the client is trained. Training materials may include descriptions of user roles and which system functions are associated with the user role, software operations descriptions, screen shots, examples, and student exercises. Training materials may also include materials on system administration procedures. Delivered To: Client Program Manager Intended For: Program Staff, IT Operational or Development Staff.

Validation and verification

Concept

Verification is a process to check whether the program is running to its specifications and validation is a process to check whether it meets the requirements (Sommerville, 2004).

The above concepts are taken into account for every program and it must be satisfied so that one is able to validate its core purpose and verify its workability.

V & V process

It is a whole life cycle process which is implemented at every stage of the product development so that every stage safeguards the use of such techniques to avoid any pitfalls at the end of the development process.

It possesses two major objectives at every stage of the life cycle:

• The discovery of defects in a system;
• The assessment of whether or not the system is useful and useable in an operational situation.

 V & V goals

The goals of the V & V process can be summarized as follows:

• Verification and validation should establish confidence that the software is fit for purpose.
• This does NOT mean completely free of defects.
• Rather, it must be good enough for its intended use and the type of use will determine the degree of confidence that is needed.

 V & V confidence

It truly depends on system’s purpose, user expectations and marketing environment:

 Software function

• The level of confidence depends on how critical the software is to an organization.
• User expectations
• Users may have low expectations of certain kinds of software.

Marketing environment

• Getting a product to market early may be more important than finding defects in the program.

Software inspections:

Concerned with analysis of the static system representation to discover problems (static verification)

• May be supplement by tool-based document and code analysis

Software testing:

Concerned with exercising and observing product behavior (dynamic verification)

• The system is executed with test data and its operational behavior is observed.

Conclusion

Concurrent programming can be quite helpful for utilizing CPU, memory and hardware resources. They facilitate the optimum use of resources so that proper utilization of the resources can be done for running several jobs at the same time.

In real applications, databases, distributed databases and operating systems the demand for various processes to execute faster and effectively so that jobs are performed at ease.

References / Bibliography

1. Andrews, G. R., and Schneider, F. B (1983). “Concepts and Notations for Concurrent Programming.” ACM Computing Surveys 15, 1 (Mar.1983), 3-43.
2. Ben-Ari, M. Principles of Concurrent Programming (1982). Prentice Hall International.
3. Brinch Hansen, P ( 1977). The Architecture of Concurrent Programs. Englewood Cliffs, N. J.: Prentice-Hall.
4. Curtis, G. and Cobham, C (2005). Business Information Systems. 5th ed. London: Financial Times/Prentice Hall.
5. Deitel, H. M (1984). An Introduction to Operating Systems. Reading, Mass.: Addison-Wesley, 1984.
6. Dijkstra, E. W (2002). “Cooperating Sequential Processes.” Programming Languages, F. Genuys, ed. Academic Press, 1968, 43-112.
7. Galvin, Peter (2002). Operating systems concepts. Sixth edition, Winley publications.
8. Hoare, C. A. R (1974). “Monitors: An Operating System Structuring Concept.” Comm. ACM 17, 10 (1974), 549-557.
9. Hoffer, A. Jeffery (2002). Modern Systems Analysis and Design, Pearson Education.
10. Lamport, L (1989). “A Simple Approach to Specifying Concurrent Systems.” Comm. ACM 32, 1 (Jan. 1989), 32-45.
11. Laudon, Kenneth (2002). Managing Information Systems: Organization and Technology, Fourth Edition.
12. Navathe Elmasri (2003). Database Systems, Prentice Hall.
13. Scacchi, W (1987). Models of Software Evolution: Life Cycle and Process. Curriculum Module SEI-CM-10-1.0, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pa., Oct. 1987.
14. Sommerville, Ian (2004). Software Engineering, Pearson Education.

Appendices

Here is the list of abbreviations used in the text.

ICT – ITSC Chief Technologist

IED – ITSC Executive Director

ISC – ITSC Software Council

ITSC – Information Technology Support Center

IPM – ITSC Project Manager

PAR – Project Activity Repository

PCO – Project Change Order

PSR – Project Status Report

PTO – Project Task Order

SDPP – Software Development Project Plan

SGM – State Grant Manager

STCO – The ITSC Steering Committee