Software Reuse Strategy

This Software Reuse Strategy document describes software reuse as a powerful concept. The value of this approach has been demonstrated in many other engineering disciplines, where the use of standard concepts, processes, and components allows prior accomplishments to be leveraged and speeds innovation for future systems. At this point, many different techniques, which support reuse, are being implemented. This document provides the focus under which these efforts will continue, lessons-learned will be collected, and experiences shared. Taken together, the ten strategic steps will bring about the cultural change necessary to make software reuse effective.

To know more click – http://www.beanarchitect.com/srs.html and download the .pdf file.

Courtesy: www.beanarchitect.com – White Papers.

Software Development Life Cycle

Software Development Life Cycle    

 INITIAL PROPOSAL PHASE

The initial proposal phase is to understand and identify the broad software requirements and main features proposed in the application. It may also involve a discovery process for new methods or technologies. The intent is to develop a relationship with the client and address at a high level the issues, costs and schedules that will be required to create the proposed application.

The deliverables for this phase are:

·         A rough estimate for effort or price for all phases of the entire Software 

·         A rough schedule for all phases of the entire software

·         An initial Function Point Analysis for all phases of the entire software 

·         A contract proposal for both of the Process Engineering Phases – Requirements Analysis and Specifications 

REQUIREMENTS ANALYSIS

The objective of the Requirements Analysis phase is to identify and document the user requirements for a proposed system. The process involves Analysts from software development team who meet with, interview, and observe knowledgeable users to understand what the requirements are. In addition existing systems, processes, documents, and procedures are reviewed and included as appropriate. From the available information the analyst develops a list of the actors, use cases and system level requirements for the software. With the help of key users the list of use cases and requirements is reviewed, refined and updated in an iterative fashion until the user is satisfied that it represents the essence of the proposed system.

The deliverables for this phase are:

·         A final Requirements Analysis document delivered for approval

SPECIFICATIONS

The objective of the Specifications phase is to distill the requirements into the functions and features the new system will have, to describe and prototype the functions and features as a user would actually see them, and to describe how users would interact with the system. In addition, the system architecture is described, including hardware, external interfaces and network requirements. Preliminary data elements, user interfaces, outputs and other interfaces are also described.

The deliverables for this phase are:

·         The Functional Specification defines the precise functions of the system. It defines the exact inputs, the actions taken based on user input, the actions taken based on user requests, and the exact outputs by the system. The inputs, actions and outputs are defined as “functions”. This is not a design document. This document does not define “how” the inputs, actions and outputs occur and are implemented, it only defines exactly “what” inputs, actions and outputs occur. This document includes enough prototype screens and reports to clearly define Functional Specifications of the system. It also includes logical data diagrams, and work and process flows present in the system. 

·         The Architectural Specification defines the system architecture that will enable a system to perform the functions defined in the Functional Specification. This document defines the system components, database components and other components required to perform these functions. These components are only described at a high level to enable a technical contact from the customer or a system administrator to understand how the new system will fit into the current environment of the customer. It is left to the design document, created in the next phase, to define in detail each of these components. This document further defines the interaction of these components and the message flow between components.

DESIGN PHASE

The design phase is the process of designing exactly how the specifications are to be implemented. It defines specifically how the software is to be written including an object model with properties and methods for each object and a detailed database design.

The deliverables for this phase are:

·         A final Design Specification. There is no approval required for this document.

·         Performance testing and small prototypes are done to demonstrate technical feasibility. 

DEVELOPMENT PHASE

The development phase involves the actual coding of the entire application. This is usually the longest and most resource-intensive phase. As components of the application are complete, they are reviewed by the customer for accuracy as well as usability, according to a milestone schedule that is part of the software schedule. There is also an alpha deployment test phase embedded in the Development Phase.

The deliverables for this phase are:

·         A beta version of the application 

·         Preliminary manuals and user documentation

·         Preliminary as-built technical documentation 

·         A test plan for final product acceptance 

TEST PHASE

The test phase involves a formal walk through of the entire test specification and modification to the application where appropriate. This is done first by SDLC Testers, and then verified by the customer.

The deliverables for this phase are:

·         A final version of the completed application

Other deliverables to complete the Development and Test phases are: 

·         A completed version of the test specification 

·         Final manuals and user documentation 

·         Final technical documentation 

DEPLOYMENT PHASE

The deployment phase is a staged roll out of the new application. This involves installation and initial training and may involve hardware and network upgrades. 

SUPPORT PHASE

The support phase of the software development is the last component and it continues as long as a warranty, extended warranty, or support contract is in place. 

Courtesy: www.BeanArchitect.com

Link: http://www.beanarchitect.com/sdlc.html

Digital Signature Security

Trust decisions are everywhere. This perception marked the beginning of the Digital Signature Initiative’s (DSig) work. Users want to make sure that the code they just downloaded does not mess with their machine – they want to know if they can trust the author of the program. Users want to verify the authenticity of an online price list before placing an order – they want to know if they can trust the contents of the document. The purpose of DSig is to help users to decide what information they can trust on the Web. One part of DSig allows the author of a (Web) document to make assertions about the document and to cryptographically protect these assertions by digital signatures. The other part of DSig, the Trust Management Architecture (TMA) described in this document, helps the recipient of a document to make a decision about how to treat this document based on the assertions, the trust relationship with sender of the document, and other parameters. Expressing trust is a complicated issue. Users need to –

·         State their security policies, including for which operations they trust whom

·         Make use of machine-readable assertions, which may or may not be signed

·         Have tools to automate parts of the decision making process.

To know more please click – http://www.beanarchitect.com/dssa.html

Article Courtesy:  www.beanarchitect.com