I have started reading the book 'The deign of everyday things' by Donald A.Norman...Seems like an awesome book to me.
Right now i am pretty high on Usability and stuff and infact I have now started criticising /analysing almost all things in this respect.Today,While using an elevator to 'The cheezecake Fcatory'I made a bigdeal about the elevators button.But they were confusing .Two buttons and in the middle of the 2 it said Restaurant...????
7/19/2007
7/16/2007
ConfuSion!!!!
More often than not simple things are so complicated to use.How many times has it happened that you would get confused looking at simple things and wonder why was it designed this way.Why weren't users considered while designing this device....Happens with me all the time.Given sometime obviously it can be figured out how various things can be used or work ..But why invest that amount of time and why not be exposed to designs that are self explanatory!!!!!!!!!!!
There are hundreds of things in life to understand and why the hell should I or anybody invest the time in thinking what was the thought process while designing this thing and try and employ the same thought process to realise how to use it...
There are hundreds of things in life to understand and why the hell should I or anybody invest the time in thinking what was the thought process while designing this thing and try and employ the same thought process to realise how to use it...
Him and I - 09/08/2000 till eternity
You fill up my senses like a night in a forest Like the mountains in springtime, like a walk in the rain Like a storm in the desert, like a sleepy blue ocean You fill up my senses come fill me again. Come let me love you, let me give my life to you Let me drown in your laughter, let me die in your arms Let me lay down beside you, let me always be with you Come let me love you, come let me give my life to you.
When the night has comeAnd the land is darkAnd the moon is the only light we'll seeNo I won't be afraid, no I won't be afraidJust as long as you stand, stand by me
And darlin', darlin', stand by me, oh now now stand by meStand by me, stand by me
If the sky that we look uponShould tumble and fallAnd the mountains should crumble to the seaI won't cry, I won't cry, no I won't shed a tearJust as long as you stand, stand by me
And darlin', darlin', stand by me, oh stand by meStand by me, stand by me, stand by me-e, yeah
Whenever you're in trouble won't you stand by me, oh now now stand by meOh stand by me, stand by me, stand by me
Darlin', darlin', stand by me-e, stand by meOh stand by me, stand by me, stand by me
When the night has comeAnd the land is darkAnd the moon is the only light we'll seeNo I won't be afraid, no I won't be afraidJust as long as you stand, stand by me
And darlin', darlin', stand by me, oh now now stand by meStand by me, stand by me
If the sky that we look uponShould tumble and fallAnd the mountains should crumble to the seaI won't cry, I won't cry, no I won't shed a tearJust as long as you stand, stand by me
And darlin', darlin', stand by me, oh stand by meStand by me, stand by me, stand by me-e, yeah
Whenever you're in trouble won't you stand by me, oh now now stand by meOh stand by me, stand by me, stand by me
Darlin', darlin', stand by me-e, stand by meOh stand by me, stand by me, stand by me
Usability Fan
Usability addresses the relationship between tools and their users. In order for a tool to be effective, it must allow intended users to accomplish their tasks in the best way possible. The same principle applies to computers, websites, and other software. In order for these systems to work, their users must be able to employ them effectively.
From the user's perspective usability is important because it can make the difference between performing a task accurately and completely or not, and enjoying the process or being frustrated. From the developer's perspective usability is important because it can mean the difference between the success or failure of a system. From a management point of view, software with poor usability can reduce the productivity of the workforce to a level of performance worse than without the system. In all cases, lack of usability can cost time and effort, and can greatly determine the success or failure of a system. Given a choice, people will tend to buy systems that are more user-friendly.
From the user's perspective usability is important because it can make the difference between performing a task accurately and completely or not, and enjoying the process or being frustrated. From the developer's perspective usability is important because it can mean the difference between the success or failure of a system. From a management point of view, software with poor usability can reduce the productivity of the workforce to a level of performance worse than without the system. In all cases, lack of usability can cost time and effort, and can greatly determine the success or failure of a system. Given a choice, people will tend to buy systems that are more user-friendly.
7/09/2007
Day 1
Aren't there some days in life ..when you feel so bored,sleepy ,gloomy,crazy,irritated,in short useless.Today seems like one of those days .
I don't have a lot of work to do ...Actually i do but i don't want to?Essentially i am not sure what i want to do .I guess 'non-complacency' is here to stay......
Internship Day1
3rd july 2007
Finally after days of no work i start with my internship today at BearingPoint one of the biggest consulting firms in the US।Today is kind of slow - i came in around 10ish...and after being homeless for sometime was allotted cubicle 8476।Though this cubicle belongs to सोमोने else , i have been told that i can sit till the time she doesn't come ॥STRANGE...
So,I got my laptop ,i got my badge and i have a cubicle .I am all set ,just that i don't know what to do now.Probably things will get better ..its only DAY1 right?
My office/Team sits on the 8th floor ...and my cubicle is kinda cute ,it has this huge window behind me.So many people around - but this palce is silent ..unlike TCS ...
I ate out today at Panda with a colleague ..generally though i had packed lunch..but wanted to to go out ..There are 2 malls in the vicnity...
Finally after days of no work i start with my internship today at BearingPoint one of the biggest consulting firms in the US।Today is kind of slow - i came in around 10ish...and after being homeless for sometime was allotted cubicle 8476।Though this cubicle belongs to सोमोने else , i have been told that i can sit till the time she doesn't come ॥STRANGE...
So,I got my laptop ,i got my badge and i have a cubicle .I am all set ,just that i don't know what to do now.Probably things will get better ..its only DAY1 right?
My office/Team sits on the 8th floor ...and my cubicle is kinda cute ,it has this huge window behind me.So many people around - but this palce is silent ..unlike TCS ...
I ate out today at Panda with a colleague ..generally though i had packed lunch..but wanted to to go out ..There are 2 malls in the vicnity...
Engineering processes in SDLC
SDLC: System Development Life Cycle is a software lifecycle management methodology that typically consists of five to seven phases. It most often includes requirements gathering, design, construction/test, implementation and post-implementation support. It guides the software development process and prescribes various documents and deliverables for each phase. Each successive phase of SDLC leverages the documentation and knowledge gained from the previous phases. For instance, the detailed business requirements must be known in order to determine functional design followed by technical design and coding. The tenets of SDLC are not standards per se, but merely guideposts for managing software and systems from cradle to grave.
In today's environment of increasingly complex and integrated systems, engineering methodologies are vitally important for improving the quality and predictability of software development projects. Software engineering is widely viewed as a solution to the chronic crisis of poor software quality, missed deadlines, cost overruns, and abandoned projects. Success as a software engineering professional depends on a high level of competence and confidence in software engineering methodologies.
Described below are the ten phases during which defined IT work products are created or modified. The tenth phase occurs when the system is disposed of and the task performed is either eliminated or transferred to other systems. Not every project will require that the phases be sequentially executed. However, the phases are interdependent. Depending upon the size and complexity of the project, phases may be combined or may overlap.
1. Initiation Phase
The initiation of a system (or project) begins when a business need or opportunity is identified. A Project Manager should be appointed to manage the project. This business need is documented in a Concept Proposal. After the Concept Proposal is approved, the System Concept Development Phase begins.
Deliverables:
The following deliverables shall be initiated during the Initiation Phase:
1.1 Concept Proposal - This is the need or opportunity to improve business functions. It identifies where strategic goals are not being met or mission performance needs to be improved.
2. System Concept Development Phase
Once a business need is approved, the approaches for accomplishing the concept are reviewed for feasibility and appropriateness. The Systems Boundary Document identifies the scope of the system and requires Senior Official approval and funding before beginning the Planning Phase.
Deliverables:
The following deliverables shall be initiated during the System Concept Development Phase:
2.1 System Boundary Document - Identifies the scope of a system (or capability). It should contain the high level requirements, benefits, business assumptions, and program costs and schedules. It records management decisions on the envisioned system early in its development and provides guidance on its achievement.
2.2 Cost-Benefit Analysis - Provides cost or benefit information for analyzing and evaluating alternative solutions to a problem and for making decisions about initiating, as well as continuing, the development of information technology systems. The analysis should clearly indicate the cost to conform to the architectural standards in the Technical Reference Model (TRM).
2.3 Feasibility Study - Provides an overview of a business requirement or opportunity and determines if feasible solutions exist before full life-cycle resources are committed.
2.4 Risk Management Plan - Identifies project risks and specifies the plans to reduce or mitigate the risks.
3. Planning Phase
The concept is further developed to describe how the business will operate once the approved system is implemented, and to assess how the system will impact employee and customer privacy. To ensure the products and /or services provide the required capability on-time and within budget, project resources, activities, schedules, tools, and reviews are defined. Additionally, security certification and accreditation activities begin with the identification of system security requirements and the completion of a high level vulnerability assessment.
Deliverables
3.1 Acquisition Plan
The plan is developed to help insure that needed resources can be obtained and are available when needed.
3.2 Configuration Management Plan
The CM Plan describes the process that will be used to identify, manage, control, and audit the project’s configuration. The plan should also define the configuration management structure, roles, and responsibilities to be used in executing these processes.
3.3 Quality Assurance Plan
The QA Plan documents that the delivered products satisfy contractual agreements, meet or exceed quality standards, and comply with the approved SDLC processes.
3.4 Concept of Operations
The CONOPS is a high level requirements document that provides a mechanism for users to describe their expectations from the system.
3.5 System Security Plan
A formal plan detailing the types of computer security is required for the new system based on the type of information being processed and the degree of sensitivity. Usually, those systems that contain personal information will be more closely safeguarded than most.
4. Requirements Analysis Phase
Functional user requirements are formally defined and delineate the requirements in terms of data, system performance, security, and maintainability requirements for the system. All requirements are defined to a level of detail sufficient for systems design to proceed. All requirements need to be measurable and testable and relate to the business need or opportunity identified in the Initiation Phase.
Deliverables
4.1 Functional Requirements Document
Serves as the foundation for system design and development; captures user requirements to be implemented in a new or enhanced system; the systems subject matter experts document these requirements into the requirements traceability matrix, which shows mapping of each detailed functional requirement to its source. This is a complete, user oriented functional and data requirements for the system which must be defined, analyzed, and documented to ensure that user and system requirements have been collected and documented.
All requirements must include considerations for capacity and growth. Where feasible,
I-CASE tools should be used to assist in the analysis, definition, and documentation. The requirements document should include but is not limited to records and privacy act, electronic record management, record disposition schedule, and components’ unique requirements..
4.2 Test and Evaluation Master Plan
Ensures that all aspects of the system are adequately tested and can be implemented; documents the scope, content, methodology, sequence, management of, and responsibilities for test activities. Unit, integration, and independence acceptance testing activities are performed during the development phase. Unit and integration tests are performed under the direction of the project manager. Independence acceptance testing is performed independently from the developing team and is coordinated with the Quality Assurance (QA) office. Acceptance tests will be performed in a test environment that duplicates the production environment as much as possible. They will ensure that the requirements are defined in a manner that is verifiable. They will support the traceability of the requirements form the source documentation to the design documentation to the test documentation. They will also verify the proper implementation of the functional requirements. The types of test activities discussed in the subsequent sections are identified more specifically in the Integration and Test Phase of the life cycle and are included in the test plan and test analysis report.
• Unit/Module Testing
• Subsystem Integration Testing
• Independent Security Testing
• Functional Qualification Testing
• User Acceptance Testing
• Beta Testing
4.3 Interface Control Document
The Interface Control Document (ICD) provides an outline for use in the specification of requirements imposed on one or more systems, subsystems configuration items or other system components to achieve one or more interfaces among these entities. Overall, an ICD can cover requirements for any number of interfaces between any number of systems.
4.4 Privacy Act Notice/Privacy Impact Assessment
For any system that has been determined to be an official System of Records (in terms of the criteria established by the Privacy Act (PA)), a special System of Records Notice shall be published in the Federal Register. This Notice identifies the purpose of the system; describes its routine use and what types of information and data are contained in its records; describes where and how the records are located; and identifies who the System Manager is. While the Records Management Representatives are responsible for determining if a system is a PA System of Records, it is the Project Managers’ responsibility to prepare the actual Notice for publication in the Federal Register. As with the Records Disposition Schedule, however, it is the Project Manager’s responsibility to coordinate with and assist the System Proponent in preparing the PA Notice.
The System of Records Notice shall be a required deliverable for the Requirements Analysis Phase of system development. The Privacy Impact Assessment is also a deliverable in this Phase. This is a written evaluation of the impact that the implementation of the proposed system would have on privacy.
5. Design Phase
The physical characteristics of the system are designed during this phase. The operating environment is established, major subsystems and their inputs and outputs are defined, and processes are allocated to resources. Everything requiring user input or approval must be documented and reviewed by the user. The physical characteristics of the system are specified and a detailed design is prepared. Subsystems identified during design are used to create a detailed structure of the system. Each subsystem is partitioned into one or more design units or modules. Detailed logic specifications are prepared for each software module.
Deliverables
The content of these deliverables may be expanded or abbreviated depending on the size, scope, and complexity of the corresponding systems development effort.
5.1 Security Risk Assessment
The purpose of the risk assessment is to analyze threats to and vulnerabilities of a system to determine the risks (potential for losses), and using the analysis as a basis for identifying appropriate and cost-effective measures.
5.2 Conversion Plan
The Conversion Plan describes the strategies involved in converting data from an existing system to another hardware or software environment. It is appropriate to re-examine the original system’s functional requirements for the condition of the system before conversion to determine if the original requirements are still valid.
5.3 System Design Document
Describes the system requirements, operating environment, system and subsystem architecture, files and database design, input formats, output layouts, human-machine interface, detailed design, processing logic, and external interfaces. It is used in conjunction with the Functional Requirements Document (FRD), which is finalized in this phase, to provide a complete system specification of all user requirements for the system and reflects the user’s perspective of the system design. Includes all information required for the review and approval of the project development. The sections and subsections of the design document may be organized, rearranged, or repeated as necessary to reflect the best organization for a particular project.
5.4 Implementation Plan
The Implementation Plan describes how the information system will be deployed and installed into an operational system. The plan contains an overview of the system, a brief description of the major tasks involved in the implementation, the overall resources needed to support the implementation effort (such as hardware, software, facilities, materials, and personnel), and any site-specific implementation requirements. This plan is updated during the Development Phase; the final version is provided in the Integration and Test Phase and used for guidance during the Implementation Phase.
5.5 Maintenance Manual
The Maintenance Manual provides maintenance personnel with the information necessary to maintain the system effectively. The manual provides the definition of the software support environment, the roles and responsibilities of maintenance personnel, and the regular activities essential to the support and maintenance of program modules, job streams, and database structures. In addition to the items identified for inclusion in the Maintenance Manual, additional information may be provided to facilitate the maintenance and modification of the system. Appendices to document various maintenance procedures, standards, or other essential information may be added to this document as needed.
5.6 Operations Manual or Systems Administration Manual
For mainframe systems, the Operations Manual provides computer control personnel and computer operators with a detailed operational description of the information system and its associated environments, such as machine room operations and procedures. The Systems Administration Manual serves the purpose of an Operations Manual in distributed (client/server) applications.
5.7 Training Plan
The Training Plan outlines the objectives, needs, strategy, and curriculum to be addressed when training users on the new or enhanced information system. The plan presents the activities needed to support the development of training materials, coordination of training schedules, reservation of personnel and facilities, planning for training needs, and other training-related tasks. Training activities are developed to teach user personnel the use of the system as specified in the training criteria. Includes the target audience and topics on which training must be conducted on the list of training needs. It includes, in the training strategy, how the topics will be addressed and the format of the training program, the list of topics to be covered, materials, time, space requirements, and proposed schedules.
5.8 User Manual
The User Manual contains all essential information for the user to make full use of the information system. This manual includes a description of the system functions and capabilities, contingencies and alternate modes of operation, and step-by-step procedures for system access and use.
6. Development Phase
The detailed specifications produced during the design phase are translated into hardware, communications, and executable software. Software shall be unit tested, integrated, and retested in a systematic manner. Hardware is assembled and tested.
Deliverables
The content of these deliverables may be expanded or abbreviated depending on the size, scope, and complexity of the corresponding systems development effort. The following deliverables shall be initiated during the Development Phase:
6.1 Contingency Plan
The Contingency Plan contains emergency response procedures; backup arrangements, procedures, and responsibilities; and post-disaster recovery procedures and responsibilities.
It is an emergency response plan, developed in conjunction with application owners and maintained at the primary and backup computer installation to ensure that a reasonable continuity of support is provided if events occur that could prevent normal operations. Contingency plans shall be routinely reviewed, updated, and tested to enable vital operations and resources to be restored as quickly as possible and to keep system downtime to an absolute minimum. A Contingency Plan is synonymous with a disaster plan and an emergency plan. If the system/subsystem is to be located within a facility with an acceptable contingency plan, system-unique contingency requirements should be added as an annex to the existing facility contingency plan.
6.2 Software Development Document
Contains documentation pertaining to the development of each unit or module, including the test cases, software, test results, approvals, and any other items that will help explain the functionality of the software
6.3 System (Application) Software
This is the actual software developed. It is used for the Test and Integration Phase and finalized before implementation of the system. Include all the disks (or other medium) used to store the information.
6.4 Test Files/Data
All the information used for system testing should be provided at the end of this phase. Provide the actual test data and files used.
6.5 Integration Document
The Integration Document explains how the software components, hardware components, or both are combined and the interaction between them.
7. Integration and Test Phase
The various components of the system are integrated and systematically tested. The user tests the system to ensure that the functional requirements, as defined in the functional requirements document, are satisfied by the developed or modified system. Prior to installing and operating the system in a production environment, the system must undergo certification and accreditation activities.
Deliverables
The following deliverables shall be initiated during the Integration and Test Phase:
7.1 Test Analysis Report
This report documents each test - unit/module, subsystem integration, system, user acceptance and security.
7.2 Test Analysis Approval Determination
Attached to the test analysis report as a final result of the test reviews and testing levels above the integration test; briefly summarizes the perceived readiness for migration of the software.
7.3 Test Problem Report
Document problems encountered during testing; the form is attached to the test analysis reports.
7.4 IT Systems Security Certification & Accreditation
The documents needed to obtain certification and accreditation of an information system before it becomes operational. They include: System Security Plan; Rules of Behavior; Configuration Management Plan, Risk Assessment; Security Test & Evaluation; Contingency Plan; Privacy Impact Assessments; and the certification and accreditation memorandums. The Systems Security Plan and certification/accreditation package should be approved prior to implementation.
8. Implementation Phase
The system or system modifications are installed and made operational in a production environment. The phase is initiated after the system has been tested and accepted by the user. This phase continues until the system is operating in production in accordance with the defined user requirements.
Deliverables
The following deliverables are initiated during the Implementation Phase:
8.1 Delivered System
After the Implementation Phase Review and Approval Certification is signed by the Project Manager and the System Proponent representative, the system - including the production version of the data repository - is delivered to the customer for the Operations and Maintenance Phase.
8.2 Change Implementation Notice
A formal request and approval document for changes made during the Implementation Phase.
8.3 Version Description Document
The primary configuration control document used to track and control versions of software released to the operational environment. It is a summary of the features and contents for the software build and identifies and describes the version of the software being delivered.
8.4 Post-Implementation Review
The review is conducted at the end of the Implementation Phase. A post-implementation review shall be conducted to ensure that the system functions as planned and expected; to verify that the system cost is within the estimated amount; and to verify that the intended benefits are derived as projected. Normally, this shall be a one-time review, and it occurs after a major implementation; it may also occur after a major enhancement to the system. The results of an unacceptable review are submitted to the System Proponent for its review and follow-up actions. The System Proponent may decide it will be necessary to return the deficient system to the responsible system development Project Manager for correction of deficiencies.
9. Operations and Maintenance Phase
The system operation is ongoing. The system is monitored for continued performance in accordance with user requirements, and needed system modifications are incorporated. The operational system is periodically assessed through In-Process Reviews to determine how the system can be made more efficient and effective. Operations continue as long as the system can be effectively adapted to respond to an organization’s needs. When modifications or changes are identified as necessary, the system may reenter the planning phase.
Deliverables
9.1 In-Process Review Report
The In-Process Review (IPR) occurs at predetermined milestones usually quarterly, but at least once a year. The performance measures should be reviewed along with the health of the system. Performance measures should be measured against the baseline measures. Ad hoc reviews should be called when deemed necessary by either party. Document the results of this review in the IPR Report.
9.2 User Satisfaction Review Report
User Satisfaction Reviews can be used as a tool to determine the current user satisfaction with the performance capabilities of an existing application or initiate a proposal for a new system. This review can be used as input to the IPR Report.
10. Disposition Phase
The disposition activities ensure the orderly termination of the system and preserve the vital information about the system so that some or all of the information may be reactivated in the future if necessary. Particular emphasis is given to proper preservation of the data processed by the system, so that the data is effectively migrated to another system or archived in accordance with applicable records management regulations and policies, for potential future access.
Deliverables
The following deliverables are initiated and finalized during the Disposition Phase
10.1 Disposition Plan
The objectives of the plan are to end the operation of the system in a planned, orderly manner and to ensure that system components and data are properly archived or incorporated into other systems. This will include removing the active support by the operations and maintenance organizations. The users will need to play an active role in the transition. All concerned groups will need to be kept informed of the progress and target dates. The decision to proceed with Disposition will be based on
Recommendations and approvals from an In-Process Review or based on a date (or time period) specified in the System Boundary Document (SBD).
This plan will include a statement of why the application is no longer supported, a description of replacement / upgrade, list of tasks/activities (transition plan) with estimated dates of completion and the notification strategy. Additionally, it will include the responsibilities for future residual support issues such as identifying media alternatives if technology changes; new software product transition plans and alternative support issues (once the application is removed); parallel operations of retiring and the new software product; archiving of the software product, associated documentation, movement of logs, code; and accessibility of archive, data protection identification, and audit applicability.
10.2 Post-Termination Review Report
A report at the end of the process that details the findings of the Disposition Phase review. It includes details of where to find all products and documentation that has been archived.
10.3 Archived System
The packaged set of data and documentation containing the archived application.
DOCUMENTATION
The life cycle methodology specifies which documentation shall be generated during each phase.
Some documentation remains unchanged throughout the systems life cycle while others evolve continuously during the life cycle. Other documents are revised to reflect the results of analyses performed in later phases. Each of the documents produced are collected and stored in a project file. Care should be taken, however, when processes are automated. Specifically, components are encouraged to incorporate a long-term retention and access policy for electronic processes.
The table below shows the life of a document through different phases:
SDLC: System Development Life Cycle is a software lifecycle management methodology that typically consists of five to seven phases. It most often includes requirements gathering, design, construction/test, implementation and post-implementation support. It guides the software development process and prescribes various documents and deliverables for each phase. Each successive phase of SDLC leverages the documentation and knowledge gained from the previous phases. For instance, the detailed business requirements must be known in order to determine functional design followed by technical design and coding. The tenets of SDLC are not standards per se, but merely guideposts for managing software and systems from cradle to grave.
In today's environment of increasingly complex and integrated systems, engineering methodologies are vitally important for improving the quality and predictability of software development projects. Software engineering is widely viewed as a solution to the chronic crisis of poor software quality, missed deadlines, cost overruns, and abandoned projects. Success as a software engineering professional depends on a high level of competence and confidence in software engineering methodologies.
Described below are the ten phases during which defined IT work products are created or modified. The tenth phase occurs when the system is disposed of and the task performed is either eliminated or transferred to other systems. Not every project will require that the phases be sequentially executed. However, the phases are interdependent. Depending upon the size and complexity of the project, phases may be combined or may overlap.
1. Initiation Phase
The initiation of a system (or project) begins when a business need or opportunity is identified. A Project Manager should be appointed to manage the project. This business need is documented in a Concept Proposal. After the Concept Proposal is approved, the System Concept Development Phase begins.
Deliverables:
The following deliverables shall be initiated during the Initiation Phase:
1.1 Concept Proposal - This is the need or opportunity to improve business functions. It identifies where strategic goals are not being met or mission performance needs to be improved.
2. System Concept Development Phase
Once a business need is approved, the approaches for accomplishing the concept are reviewed for feasibility and appropriateness. The Systems Boundary Document identifies the scope of the system and requires Senior Official approval and funding before beginning the Planning Phase.
Deliverables:
The following deliverables shall be initiated during the System Concept Development Phase:
2.1 System Boundary Document - Identifies the scope of a system (or capability). It should contain the high level requirements, benefits, business assumptions, and program costs and schedules. It records management decisions on the envisioned system early in its development and provides guidance on its achievement.
2.2 Cost-Benefit Analysis - Provides cost or benefit information for analyzing and evaluating alternative solutions to a problem and for making decisions about initiating, as well as continuing, the development of information technology systems. The analysis should clearly indicate the cost to conform to the architectural standards in the Technical Reference Model (TRM).
2.3 Feasibility Study - Provides an overview of a business requirement or opportunity and determines if feasible solutions exist before full life-cycle resources are committed.
2.4 Risk Management Plan - Identifies project risks and specifies the plans to reduce or mitigate the risks.
3. Planning Phase
The concept is further developed to describe how the business will operate once the approved system is implemented, and to assess how the system will impact employee and customer privacy. To ensure the products and /or services provide the required capability on-time and within budget, project resources, activities, schedules, tools, and reviews are defined. Additionally, security certification and accreditation activities begin with the identification of system security requirements and the completion of a high level vulnerability assessment.
Deliverables
3.1 Acquisition Plan
The plan is developed to help insure that needed resources can be obtained and are available when needed.
3.2 Configuration Management Plan
The CM Plan describes the process that will be used to identify, manage, control, and audit the project’s configuration. The plan should also define the configuration management structure, roles, and responsibilities to be used in executing these processes.
3.3 Quality Assurance Plan
The QA Plan documents that the delivered products satisfy contractual agreements, meet or exceed quality standards, and comply with the approved SDLC processes.
3.4 Concept of Operations
The CONOPS is a high level requirements document that provides a mechanism for users to describe their expectations from the system.
3.5 System Security Plan
A formal plan detailing the types of computer security is required for the new system based on the type of information being processed and the degree of sensitivity. Usually, those systems that contain personal information will be more closely safeguarded than most.
4. Requirements Analysis Phase
Functional user requirements are formally defined and delineate the requirements in terms of data, system performance, security, and maintainability requirements for the system. All requirements are defined to a level of detail sufficient for systems design to proceed. All requirements need to be measurable and testable and relate to the business need or opportunity identified in the Initiation Phase.
Deliverables
4.1 Functional Requirements Document
Serves as the foundation for system design and development; captures user requirements to be implemented in a new or enhanced system; the systems subject matter experts document these requirements into the requirements traceability matrix, which shows mapping of each detailed functional requirement to its source. This is a complete, user oriented functional and data requirements for the system which must be defined, analyzed, and documented to ensure that user and system requirements have been collected and documented.
All requirements must include considerations for capacity and growth. Where feasible,
I-CASE tools should be used to assist in the analysis, definition, and documentation. The requirements document should include but is not limited to records and privacy act, electronic record management, record disposition schedule, and components’ unique requirements..
4.2 Test and Evaluation Master Plan
Ensures that all aspects of the system are adequately tested and can be implemented; documents the scope, content, methodology, sequence, management of, and responsibilities for test activities. Unit, integration, and independence acceptance testing activities are performed during the development phase. Unit and integration tests are performed under the direction of the project manager. Independence acceptance testing is performed independently from the developing team and is coordinated with the Quality Assurance (QA) office. Acceptance tests will be performed in a test environment that duplicates the production environment as much as possible. They will ensure that the requirements are defined in a manner that is verifiable. They will support the traceability of the requirements form the source documentation to the design documentation to the test documentation. They will also verify the proper implementation of the functional requirements. The types of test activities discussed in the subsequent sections are identified more specifically in the Integration and Test Phase of the life cycle and are included in the test plan and test analysis report.
• Unit/Module Testing
• Subsystem Integration Testing
• Independent Security Testing
• Functional Qualification Testing
• User Acceptance Testing
• Beta Testing
4.3 Interface Control Document
The Interface Control Document (ICD) provides an outline for use in the specification of requirements imposed on one or more systems, subsystems configuration items or other system components to achieve one or more interfaces among these entities. Overall, an ICD can cover requirements for any number of interfaces between any number of systems.
4.4 Privacy Act Notice/Privacy Impact Assessment
For any system that has been determined to be an official System of Records (in terms of the criteria established by the Privacy Act (PA)), a special System of Records Notice shall be published in the Federal Register. This Notice identifies the purpose of the system; describes its routine use and what types of information and data are contained in its records; describes where and how the records are located; and identifies who the System Manager is. While the Records Management Representatives are responsible for determining if a system is a PA System of Records, it is the Project Managers’ responsibility to prepare the actual Notice for publication in the Federal Register. As with the Records Disposition Schedule, however, it is the Project Manager’s responsibility to coordinate with and assist the System Proponent in preparing the PA Notice.
The System of Records Notice shall be a required deliverable for the Requirements Analysis Phase of system development. The Privacy Impact Assessment is also a deliverable in this Phase. This is a written evaluation of the impact that the implementation of the proposed system would have on privacy.
5. Design Phase
The physical characteristics of the system are designed during this phase. The operating environment is established, major subsystems and their inputs and outputs are defined, and processes are allocated to resources. Everything requiring user input or approval must be documented and reviewed by the user. The physical characteristics of the system are specified and a detailed design is prepared. Subsystems identified during design are used to create a detailed structure of the system. Each subsystem is partitioned into one or more design units or modules. Detailed logic specifications are prepared for each software module.
Deliverables
The content of these deliverables may be expanded or abbreviated depending on the size, scope, and complexity of the corresponding systems development effort.
5.1 Security Risk Assessment
The purpose of the risk assessment is to analyze threats to and vulnerabilities of a system to determine the risks (potential for losses), and using the analysis as a basis for identifying appropriate and cost-effective measures.
5.2 Conversion Plan
The Conversion Plan describes the strategies involved in converting data from an existing system to another hardware or software environment. It is appropriate to re-examine the original system’s functional requirements for the condition of the system before conversion to determine if the original requirements are still valid.
5.3 System Design Document
Describes the system requirements, operating environment, system and subsystem architecture, files and database design, input formats, output layouts, human-machine interface, detailed design, processing logic, and external interfaces. It is used in conjunction with the Functional Requirements Document (FRD), which is finalized in this phase, to provide a complete system specification of all user requirements for the system and reflects the user’s perspective of the system design. Includes all information required for the review and approval of the project development. The sections and subsections of the design document may be organized, rearranged, or repeated as necessary to reflect the best organization for a particular project.
5.4 Implementation Plan
The Implementation Plan describes how the information system will be deployed and installed into an operational system. The plan contains an overview of the system, a brief description of the major tasks involved in the implementation, the overall resources needed to support the implementation effort (such as hardware, software, facilities, materials, and personnel), and any site-specific implementation requirements. This plan is updated during the Development Phase; the final version is provided in the Integration and Test Phase and used for guidance during the Implementation Phase.
5.5 Maintenance Manual
The Maintenance Manual provides maintenance personnel with the information necessary to maintain the system effectively. The manual provides the definition of the software support environment, the roles and responsibilities of maintenance personnel, and the regular activities essential to the support and maintenance of program modules, job streams, and database structures. In addition to the items identified for inclusion in the Maintenance Manual, additional information may be provided to facilitate the maintenance and modification of the system. Appendices to document various maintenance procedures, standards, or other essential information may be added to this document as needed.
5.6 Operations Manual or Systems Administration Manual
For mainframe systems, the Operations Manual provides computer control personnel and computer operators with a detailed operational description of the information system and its associated environments, such as machine room operations and procedures. The Systems Administration Manual serves the purpose of an Operations Manual in distributed (client/server) applications.
5.7 Training Plan
The Training Plan outlines the objectives, needs, strategy, and curriculum to be addressed when training users on the new or enhanced information system. The plan presents the activities needed to support the development of training materials, coordination of training schedules, reservation of personnel and facilities, planning for training needs, and other training-related tasks. Training activities are developed to teach user personnel the use of the system as specified in the training criteria. Includes the target audience and topics on which training must be conducted on the list of training needs. It includes, in the training strategy, how the topics will be addressed and the format of the training program, the list of topics to be covered, materials, time, space requirements, and proposed schedules.
5.8 User Manual
The User Manual contains all essential information for the user to make full use of the information system. This manual includes a description of the system functions and capabilities, contingencies and alternate modes of operation, and step-by-step procedures for system access and use.
6. Development Phase
The detailed specifications produced during the design phase are translated into hardware, communications, and executable software. Software shall be unit tested, integrated, and retested in a systematic manner. Hardware is assembled and tested.
Deliverables
The content of these deliverables may be expanded or abbreviated depending on the size, scope, and complexity of the corresponding systems development effort. The following deliverables shall be initiated during the Development Phase:
6.1 Contingency Plan
The Contingency Plan contains emergency response procedures; backup arrangements, procedures, and responsibilities; and post-disaster recovery procedures and responsibilities.
It is an emergency response plan, developed in conjunction with application owners and maintained at the primary and backup computer installation to ensure that a reasonable continuity of support is provided if events occur that could prevent normal operations. Contingency plans shall be routinely reviewed, updated, and tested to enable vital operations and resources to be restored as quickly as possible and to keep system downtime to an absolute minimum. A Contingency Plan is synonymous with a disaster plan and an emergency plan. If the system/subsystem is to be located within a facility with an acceptable contingency plan, system-unique contingency requirements should be added as an annex to the existing facility contingency plan.
6.2 Software Development Document
Contains documentation pertaining to the development of each unit or module, including the test cases, software, test results, approvals, and any other items that will help explain the functionality of the software
6.3 System (Application) Software
This is the actual software developed. It is used for the Test and Integration Phase and finalized before implementation of the system. Include all the disks (or other medium) used to store the information.
6.4 Test Files/Data
All the information used for system testing should be provided at the end of this phase. Provide the actual test data and files used.
6.5 Integration Document
The Integration Document explains how the software components, hardware components, or both are combined and the interaction between them.
7. Integration and Test Phase
The various components of the system are integrated and systematically tested. The user tests the system to ensure that the functional requirements, as defined in the functional requirements document, are satisfied by the developed or modified system. Prior to installing and operating the system in a production environment, the system must undergo certification and accreditation activities.
Deliverables
The following deliverables shall be initiated during the Integration and Test Phase:
7.1 Test Analysis Report
This report documents each test - unit/module, subsystem integration, system, user acceptance and security.
7.2 Test Analysis Approval Determination
Attached to the test analysis report as a final result of the test reviews and testing levels above the integration test; briefly summarizes the perceived readiness for migration of the software.
7.3 Test Problem Report
Document problems encountered during testing; the form is attached to the test analysis reports.
7.4 IT Systems Security Certification & Accreditation
The documents needed to obtain certification and accreditation of an information system before it becomes operational. They include: System Security Plan; Rules of Behavior; Configuration Management Plan, Risk Assessment; Security Test & Evaluation; Contingency Plan; Privacy Impact Assessments; and the certification and accreditation memorandums. The Systems Security Plan and certification/accreditation package should be approved prior to implementation.
8. Implementation Phase
The system or system modifications are installed and made operational in a production environment. The phase is initiated after the system has been tested and accepted by the user. This phase continues until the system is operating in production in accordance with the defined user requirements.
Deliverables
The following deliverables are initiated during the Implementation Phase:
8.1 Delivered System
After the Implementation Phase Review and Approval Certification is signed by the Project Manager and the System Proponent representative, the system - including the production version of the data repository - is delivered to the customer for the Operations and Maintenance Phase.
8.2 Change Implementation Notice
A formal request and approval document for changes made during the Implementation Phase.
8.3 Version Description Document
The primary configuration control document used to track and control versions of software released to the operational environment. It is a summary of the features and contents for the software build and identifies and describes the version of the software being delivered.
8.4 Post-Implementation Review
The review is conducted at the end of the Implementation Phase. A post-implementation review shall be conducted to ensure that the system functions as planned and expected; to verify that the system cost is within the estimated amount; and to verify that the intended benefits are derived as projected. Normally, this shall be a one-time review, and it occurs after a major implementation; it may also occur after a major enhancement to the system. The results of an unacceptable review are submitted to the System Proponent for its review and follow-up actions. The System Proponent may decide it will be necessary to return the deficient system to the responsible system development Project Manager for correction of deficiencies.
9. Operations and Maintenance Phase
The system operation is ongoing. The system is monitored for continued performance in accordance with user requirements, and needed system modifications are incorporated. The operational system is periodically assessed through In-Process Reviews to determine how the system can be made more efficient and effective. Operations continue as long as the system can be effectively adapted to respond to an organization’s needs. When modifications or changes are identified as necessary, the system may reenter the planning phase.
Deliverables
9.1 In-Process Review Report
The In-Process Review (IPR) occurs at predetermined milestones usually quarterly, but at least once a year. The performance measures should be reviewed along with the health of the system. Performance measures should be measured against the baseline measures. Ad hoc reviews should be called when deemed necessary by either party. Document the results of this review in the IPR Report.
9.2 User Satisfaction Review Report
User Satisfaction Reviews can be used as a tool to determine the current user satisfaction with the performance capabilities of an existing application or initiate a proposal for a new system. This review can be used as input to the IPR Report.
10. Disposition Phase
The disposition activities ensure the orderly termination of the system and preserve the vital information about the system so that some or all of the information may be reactivated in the future if necessary. Particular emphasis is given to proper preservation of the data processed by the system, so that the data is effectively migrated to another system or archived in accordance with applicable records management regulations and policies, for potential future access.
Deliverables
The following deliverables are initiated and finalized during the Disposition Phase
10.1 Disposition Plan
The objectives of the plan are to end the operation of the system in a planned, orderly manner and to ensure that system components and data are properly archived or incorporated into other systems. This will include removing the active support by the operations and maintenance organizations. The users will need to play an active role in the transition. All concerned groups will need to be kept informed of the progress and target dates. The decision to proceed with Disposition will be based on
Recommendations and approvals from an In-Process Review or based on a date (or time period) specified in the System Boundary Document (SBD).
This plan will include a statement of why the application is no longer supported, a description of replacement / upgrade, list of tasks/activities (transition plan) with estimated dates of completion and the notification strategy. Additionally, it will include the responsibilities for future residual support issues such as identifying media alternatives if technology changes; new software product transition plans and alternative support issues (once the application is removed); parallel operations of retiring and the new software product; archiving of the software product, associated documentation, movement of logs, code; and accessibility of archive, data protection identification, and audit applicability.
10.2 Post-Termination Review Report
A report at the end of the process that details the findings of the Disposition Phase review. It includes details of where to find all products and documentation that has been archived.
10.3 Archived System
The packaged set of data and documentation containing the archived application.
DOCUMENTATION
The life cycle methodology specifies which documentation shall be generated during each phase.
Some documentation remains unchanged throughout the systems life cycle while others evolve continuously during the life cycle. Other documents are revised to reflect the results of analyses performed in later phases. Each of the documents produced are collected and stored in a project file. Care should be taken, however, when processes are automated. Specifically, components are encouraged to incorporate a long-term retention and access policy for electronic processes.
The table below shows the life of a document through different phases:
Incremental Build Life Cycle Model
Software process models often represent a networked sequence of activities, objects, transformations, and events that embody strategies for accomplishing software evolution. Such models can be used to develop more precise and formalized descriptions of software life cycle activities.
One such model that helps reduce cycle time is the Incremental model (A prescriptive model which describes how a new software system should be developed). It allows the system to be delivered in pieces .Thus, the user can have some functionality while the rest is being developed.
Generally 2 systems work in parallel for this:
· The operational System - The one currently being used
· The development System - Next version which would add some more functionality to the existing system
The incremental approach attempts to analyze each iteration through 2 views essentially, the user view and the developer’s view and incorporates the feedback to modify both the language requirements and any design related changes for future iterations. The development is done in an open loop with user feedback being an essential factor.
It primarily combines the waterfall sequence with some of the advantages of prototyping. There are two fundamental flaws in the traditional (waterfall or modified waterfall) software development life cycle model: the information flow is unidirectional with inadequate provisions for feedback and user involvement is focused primarily only at the beginning and end of the project. The iterative process addresses these flaws by using a shorter life cycle and allowing efficiently for feedback from later stages to earlier ones.
In general it divides the project into a number of increments and then applies the waterfall model to each increment. The system is put into production when the first increment is delivered. Over the time additional increments are completed and added to the working system. Each iteration passes through the requirements, design, implementation and testing phases. The Incremental model allows full SDLC of prototypes to be made and then tested before moving to next level.
Research indicates that developing software components early and often and within smaller time frames increases the success rate .Complex systems are most successful when they are implemented in short steps and each step has a specific and clear objective. (A classic example of this is NASA’s space shuttle software –The primary avionics system built from 1977 to 1980). This approach gives an opportunity of receiving feedback from the real world before actually creating the whole system and a chance to correct some design errors in the first few stages before they prove fatal.
The defined phases are:
Initial Planning - understanding the project, preliminary planning and estimating.
Requirement Analysis phase - identification of requirements, detailed planning
Design phase- transform the detailed, defined requirements into system design, develop a complete information system
Deployment –product packaging and delivery, user training, user product evaluation.
Operations Mode – Maintenance of the product.
Each phase consists of a number of iterations which are planned, controlled and analyzed.
Put succinctly, the incremental process breaks the entire project into smaller sub-cycles. Each sub cycle delivers a subset of the overall system functionality to the end user, explicitly validates the requirements, and involves the end users more intimately in the development process.
From a project management perspective, the incremental life cycle seems to be hard to plan and a nightmare to track. It can be unmanageable in an absence of an experienced project manger and architect. Incremental development places a much greater premium on a sound architectural framework based on a solid use case analysis. But when the process is managed with the appropriately skilled team members on board, it is actually easier to manage and carries drastically reduced risks of cost overruns, missed deadlines, lower quality, and failure to meet expectations.
Software process models often represent a networked sequence of activities, objects, transformations, and events that embody strategies for accomplishing software evolution. Such models can be used to develop more precise and formalized descriptions of software life cycle activities.
One such model that helps reduce cycle time is the Incremental model (A prescriptive model which describes how a new software system should be developed). It allows the system to be delivered in pieces .Thus, the user can have some functionality while the rest is being developed.
Generally 2 systems work in parallel for this:
· The operational System - The one currently being used
· The development System - Next version which would add some more functionality to the existing system
The incremental approach attempts to analyze each iteration through 2 views essentially, the user view and the developer’s view and incorporates the feedback to modify both the language requirements and any design related changes for future iterations. The development is done in an open loop with user feedback being an essential factor.
It primarily combines the waterfall sequence with some of the advantages of prototyping. There are two fundamental flaws in the traditional (waterfall or modified waterfall) software development life cycle model: the information flow is unidirectional with inadequate provisions for feedback and user involvement is focused primarily only at the beginning and end of the project. The iterative process addresses these flaws by using a shorter life cycle and allowing efficiently for feedback from later stages to earlier ones.
In general it divides the project into a number of increments and then applies the waterfall model to each increment. The system is put into production when the first increment is delivered. Over the time additional increments are completed and added to the working system. Each iteration passes through the requirements, design, implementation and testing phases. The Incremental model allows full SDLC of prototypes to be made and then tested before moving to next level.
Research indicates that developing software components early and often and within smaller time frames increases the success rate .Complex systems are most successful when they are implemented in short steps and each step has a specific and clear objective. (A classic example of this is NASA’s space shuttle software –The primary avionics system built from 1977 to 1980). This approach gives an opportunity of receiving feedback from the real world before actually creating the whole system and a chance to correct some design errors in the first few stages before they prove fatal.
The defined phases are:
Initial Planning - understanding the project, preliminary planning and estimating.
Requirement Analysis phase - identification of requirements, detailed planning
Design phase- transform the detailed, defined requirements into system design, develop a complete information system
Deployment –product packaging and delivery, user training, user product evaluation.
Operations Mode – Maintenance of the product.
Each phase consists of a number of iterations which are planned, controlled and analyzed.
Put succinctly, the incremental process breaks the entire project into smaller sub-cycles. Each sub cycle delivers a subset of the overall system functionality to the end user, explicitly validates the requirements, and involves the end users more intimately in the development process.
From a project management perspective, the incremental life cycle seems to be hard to plan and a nightmare to track. It can be unmanageable in an absence of an experienced project manger and architect. Incremental development places a much greater premium on a sound architectural framework based on a solid use case analysis. But when the process is managed with the appropriately skilled team members on board, it is actually easier to manage and carries drastically reduced risks of cost overruns, missed deadlines, lower quality, and failure to meet expectations.
Subscribe to:
Posts (Atom)