Error: Reference source not found

118463785.doc

Version Error: Reference source not found Error: Reference source not found

Revisions
Version Ver 1.0 Primary Author(s) Description of Version Reviewed\Appro ved By Diego Torres Date Completed 31/10/11

Ana Grimaldo, Initial Version Ren Prez, Juan Medina

The paragraphs written in the Comment style are for the benefit of the person writing the document and should be removed before the document is finalized. Comment Style refers to: <Comment> Italics and text in angled brackets This template serves as a basis for a Software Design Specification. Designs for software systems should be customized to the needs project building the system. This template is only a starting point; most projects should not constrain their system design to a single document.

Contents
REVISIONS........................................................................................................................I CONTENTS.......................................................................................................................II 1 INTRODUCTION...............................................................................................................1 2 DESIGN CONSIDERATIONS...............................................................................................3 3 ARCHITECTURE..............................................................................................................6 4 HIGH LEVEL DESIGN.....................................................................................................8 5 LOW LEVEL DESIGN......................................................................................................9 6 USER INTERFACE DESIGN.............................................................................................10

1 Introduction
<This space may be used to provide an introduction for the design and ties to other project materials.>

1.1 System Overview

The <Web Service Project> provides to the users the capability of communicate their applications to a Database. This interface is designed to provide a standard model for supporting several different applications. It designed under Windows Communication Foundation that provides a unified programming model for building service oriented applications that communicate across the web. This interface is build to support connections between Companys application and a centralized Database. Its structure provides the functionality of adding data like users, areas, groups, and different role using a User Management Application. The <Web Service Project> interacts with each companys application, providing it services like users validation, accessing, consultation, modification into centralized Database and sending back a response for each request in the application.

1.2 Design Map

<Summarize the information contained within this document or the family of design artifacts. Define all major design artifacts and/or major sections of this document and if appropriate, provide a brief summary of each. Discuss any significant relationships between design artifacts and other project artifacts.>

1.3 Supporting Materials

< (Optional) Note any references or related materials here>

1.4 Definitions and Acronyms

Consumer: Each application that tries to communicate with the database using the Web Service. User: The person that is going to identify itself in the Application using a User name and password. Administrator: The person that is in charge of management the Database or the Application.

~NST

Page 1\6

Web Service: Its a method of communication between two electronic devices (in this case Personal Computers) over a network. Application: Its also known as an application or an "app", is computer software designed to help the user to perform specific tasks. Computer Software: Or just software, is a collection of computer programs and related data that provide the instructions for telling a computer what to do and how to do it. In other words, software is a conceptual entity which is a set of computer programs, procedures, and associated documentation concerned with the operation of a data processing system. < (Optional) List any project definitions and acronyms introduced to the project by this design.>

~NST

Page 2\6

2 Design Considerations
<This section describes issues that need to be addressed or resolved prior to or while completing the design as well as issues that may influence the design process.>

2.1 Assumptions
The project <Web Service> is created with the need of authenticate the users who use the applications in SVAM international de Mexico, so far there is a lack of control in the access and no authenticate is provided, this represents a threat for the information managed in those applications and the integrity of the application itself. The SVAM <Web Service> is designed to run on the SVAM web server and then allow users to identify themselves so they can use the desired application. The data will be held in an SQL Centralized Database on the Web Server. <Describe any assumption, background, or dependencies of the software, its use, the operational environment, or significant project issues.>

2.2 Constraints
<Describe any constraints on the system that have a significant impact on the design of the system. (e.g. technology constraints, performance requirements, end user characteristics, validation requirements, project constraints, etc.)>

2.3 System Environment

Pending. <Describe the hardware and software that the system must operate in and interact with. >

2.4 Software Design Criteria

<Mention all the design methodologies identified for the client.>

2.4.1 Suggested Designs

Design No. Proposed Design Proposed By Yes 1. <(Description of the Design)> Feasibility No

<(Name of the <(Mention the ma- <(Mention the maperson who pro- jor advantage for jor dis-advantage

~NST

Page 3\6

posed design)> 2.

the

selecting this de- for not selecting sign)> this design)>

2.4.2 Chosen Design and Reason

Chosen Design <(Mention the Design No of the chosen design)> Reason for choosing the design <(State the reason as why this design has been chosen over others )>

2.4.3 Selection Criteria

< (Refer to DAR Process)>

2.4.4 Advantages
<Summarize major advantages of this design over others>

2.5 Design Methodology

Agile software development is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle. The Agile Manifesto introduced the term in 2001. Agile management methods can also be applied in other development projects than software development.

Well-known agile software development methods include:

Agile Modeling is intended to be a collection of values, principles, and practices for Modeling software that can be applied on a software development project in a more flexible manner

~NST

Page 4\6

Extreme Programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. Scrum: its use has focused on the management of software development projects, and it can be used to run software maintenance teams or as a general project/program management approach. Velocity tracking: Its velocity is calculated by counting the number of units of work completed in a certain interval, determined at the start of the project

<(Optional) - Summarize the approach that will be used to create and evolve the designs for this system. Cover any processes, conventions, policies, techniques or other issues which will guide design work.>

2.6 Risks and Volatile Areas

<(Optional) - Describe any notably volatile or risky areas of the system and not any special strategies taken to mitigate risks or prepare for changes.>

~NST

Page 5\6

3 Architecture
<The architecture provides the top level design view of a system and provides a basis for more detailed design work.>

3.1 Overview
The <Web Service> is available through the SVAM Mexico web page, once you enter in the page and select an application. The project <Web Service> offers 2 different types of service: The first provides service to the Application chosen by the user. In each application the user can identify itself providing its user name and password. The <Web Service> is going to take that information and check it with the Database, returning a value to the application. The information provided by the user, returns different values for the application and its needs. The second provides service for an Administrator; the administrator can manage the data such as users, groups, roles; this service is available in each companys application. The administrator can add roles, groups and users to database. <This section provides a high level overview of the structural and functional decomposition of the system. Focus on how and why the system was decomposed in a particular way rather than on details of the particular components. Include information on the major responsibilities and roles the system (or portions their of) must play.>

3.2 Subsystem, Component, or Module 1n

The components in <Web Service> are not available for anyone, but basically they operate once you have access to them entering your User ID and your password. Adding Group Module <Application><Web Service> This module allows the user in this case an Administrator to add a new Group into the Database, supplying all the required data for the creation. The Group Allows grouping the employees with a specific criteria. Adding Role Module <Application><Web Service> This module allows the user in this case an Administrator to add a new Role into the Database, supplying all the required data for the creation. The Role allows grouping the users by its privileges.

~NST

Page 6\6

Adding User Module <Application><Web Service> This module allows the user in this case an Administrator to add a new Member/User into the Database, supplying all the required data for the creation. The new User Module allows creating a new user which requires a Group/Role/User name to start using the Applications. Consulting Module <Application><Web Service> Registering Module <Application><Web Service> Updating Module <Application><Web Service> <Describe an element (subsystem, component, module, etc.) from architecture in further detail. When appropriate, include information on how the element is further broken down and the interactions and relationships between these subcomponents.>

3.2.1 Sub Element 1...n

<If appropriate, describe a sub element in further detail.>

3.3 Strategies
<This section describes the design strategies or decisions that impact the overall organization of the system. Includes information about key abstractions, methods, mechanisms, etc. which are used in the system architecture. Error handling strategies are a common example. >

3.3.1 Strategy 1..n

<Describe the strategy used or decision made. Include information on the alternatives considered and the reasons for their rejection.>

~NST

Page 7\6

4 High Level Design

<This section describes in further detail elements discussed in the Architecture. Normally this section would be split into separate documents for different areas of the design. High-level designs are most effective if they attempt to model groups of system elements from a number of different views.>

4.1 View / Model Element 1..n

<Provide a description and diagrams of a system element or set of elements that describes a clearly defined view or model of the entire system or a subset of the system.>

~NST

Page 8\6

5 Low Level Design

<This section provides low-level design descriptions that directly support construction of modules. Normally this section would be split into separate documents for different areas of the design.>

5.1 Module 1..n

<Provide or reference a detailed description and diagrams of this software module.>

~NST

Page 9\6

6 User Interface Design

<This section provides user interface design descriptions that directly support construction of user interface screens.>

6.1 Application Control

<Detail the common behavior that all screens will have. Common look and feel details such as menus, popup menus, toolbars, status bar, title bars, drag and drop mouse behavior should be described here.>

6.2 Screen 1..n

<Illustrate all major user interface screens and describe the behavior and state changes that the user will experience. A screen transition diagram or table can optionally be created to illustrate the flow of control through the various screens.>

~NST

Page 10\6