DTT Testing

Bu səhifə sonuncu dəfə 06:07, 21 iyun 2011 tarixində redaktə edilib. Bu səhifəyə 8.309 dəfə müraciət olunub.

Linguistic Team International Wiki saytından

Keçid et: naviqasiya, axtar

Date Information
2010-05-07 TZM Media Project website launch. https://launchpad.net/zeitgeist-media-project/+announcement/5783
2010-04-24 A link to the prototype of the TZM Media Project has been posted on the "Current Projects" table in the "Programming Team Projects" section.
2009-12-19 A mailing list for the team members has been enabled within the launchpad. If you want to use it, be sure that you've subscribed to it.
2009-12-18 A collaboration platform has been setup at launchpad. This software allows us store code with Bazaar, work with branches, track bugs, work on blueprints, easily contact each other and work on translations. Let's test it for few weeks and see if it would meet our needs.

Join us

Everyone is welcome to join and contribute code, documentation, ideas &/or help with testing.

If you would like to contribute within the Developers Team, please go to the Contributors page and add information about how you might want to help.

If you are a new member of the community, it may take a few days before you will gain access to the repositories.

Developers Team: How to Get Started

Greetings developers!
The Developers Team welcomes you to our community.
If you're interested in contributing, or getting involved at any level, here's a list of everything you can do to start getting involved right away.

Recommended Reading/Viewing

Information & Your Profile

  • The Global Developers Team Wiki is the central location for info related to the team
    • Add yourself to the Dev Team Members wiki page
    • Create your sandbox page in Wiki. (see example here)
    • Your sandbox can then be used to create mock-ups, format documentation, etc.
  • Create your complete user profile in the Community area
  • Setup your profile in the Forum
    • This makes it much easier for others to find you, based on the information you supply.

Project Management

  • We are using bazaar and Launchpad for version control and bug tracking
    • Not familiar with using version control systems? [1]
  • Join to the TZM team on Launchpad
  • Signup to the developers email list in (optional) [2]

Communication & Meetings

  • Setup IRC and join the #ZM-Developers channel (Note: IRC is currently offline)
    • IRC serves as an informal hangout for team members
    • IRC is also used during all VoIP meetings as a backup
  • Formal and informal meetings typically occur in TeamSpeak
  • Install Teamspeak VoIP client
  • We meet every other Sunday at 23:00 UTC/GMT
    • Unless otherwise stated, meetings are held every other week. Details are provided in the Developers Team room description of Teamspeak, as well as the main Dev Team Meetings wiki page.

Be vocal! Be involved!

Everyone's ideas and contributions are welcome.
All levels of experience are welcome.

Programming Team Charter

This is the Charter for the Programming Team of The Zeitgeist Movement. This document denotes the intent of the Programming Team to be recognized as a team of the Zeitgeist Movement, and outlines general protocols for conducting our activities.

Meetings

Meetings occur every Saturday 22:00 UTC/GMT on TeamSpeak (Creative Team - Programming Team channel)

Up-to-date details are provided in the Topic header of the #ZM-Developer's channel in IRC, as well as the Programming Team Meetings wiki page. Agendas are published in the wiki and anyone may contribute agenda items that are relevant to the Programming Team.

People

The Programming Team is open to join for anyone with programming experience or who is actively engaged in learning programming. The organization of the team is a flat structure and decisions that affect the entire team are arrived at via consensus. Currently, membership is measured according to the list in the Programming Team Wiki.

Scope

The Programming Team will serve as a resource of creative and technical support for the movement, including all Chapters and Teams, providing consultation, planning, development and maintenance to the best of our abilities, as resources permit, in accordance with the tenets of the Zeitgeist Movement.

The Programming Team will in time be connected with all other Project Teams. The Programming Team is expected to provide prompt support to the projects developed or improved and used by the movement. It is expected to develop or improve tools for the other teams to use.

Objectives

  • Support Zeitgeist Movement projects
  • Work with site admins to maintain and improve the ZM main website and applications therein
  • Provide consultation and support to members, Teams and Chapters for programming-related issues
  • Provide a structure and protocol for accepting project proposals, and managing projects
  • Maintain a helpful and welcoming community to newcomers
  • Provide a positive environment for learning, cooperation and the free flow of information

Conduct

This list highlights some of the core tenets and guidelines that the Programming Team commits to practice and uphold:

  • Apply the Scientific Method and the principles of Science whenever possible.
  • If in disagreement, do not mention specific people, but rather speak about ideas. This applies to conversation, documents and all communications media.
  • Be respectful of different views. Discuss, don't debate. Listen, educate, and strive to achieve consensus.

Changes & Amendments

This document may be altered or amended from time to time. If aspects of this document are found to be in conflict with other Charters or the general tenets of the Community, such conflicts will be addressed and resolved by consensus of all parties involved before adoption.


Team Communication Map

Prog team communication map.png

Software Engineering and Design

(from [3]) Software development activities

Planning

The important task in creating a software product is extracting the requirements or requirements analysis. Customers typically have an abstract idea of what they want as an end result, but not what software should do. Incomplete, ambiguous, or even contradictory requirements are recognized by skilled and experienced software engineers at this point. Frequently demonstrating live code may help reduce the risk that the requirements are incorrect.

Once the general requirements are gleaned from the client, an analysis of the scope of the development should be determined and clearly stated. This is often called a scope document.

Certain functionality may be out of scope of the project as a function of cost or as a result of unclear requirements at the start of development. If the development is done externally, this document can be considered a legal document so that if there are ever disputes, any ambiguity of what was promised to the client can be clarified.

Design

Domain Analysis is often the first step in attempting to design a new piece of software, whether it be an addition to an existing software, a new application, a new subsystem or a whole new system. Assuming that the developers (including the analysts) are not sufficiently knowledgeable in the subject area of the new software, the first task is to investigate the so-called "domain" of the software. The more knowledgeable they are about the domain already, the less work required. Another objective of this work is to make the analysts, who will later try to elicit and gather the requirements from the area experts, speak with them in the domain's own terminology, facilitating a better understanding of what is being said by these experts. If the analyst does not use the proper terminology it is likely that they will not be taken seriously, thus this phase is an important prelude to extracting and gathering the requirements. If an analyst hasn't done the appropriate work confusion may ensue: "I know you believe you understood what you think I said, but I am not sure you realize what you heard is not what I meant."[1]

Specification

Specification is the task of precisely describing the software to be written, possibly in a rigorous way. In practice, most successful specifications are written to understand and fine-tune applications that were already well-developed, although safety-critical software systems are often carefully specified prior to application development. Specifications are most important for external interfaces that must remain stable. A good way to determine whether the specifications are sufficiently precise is to have a third party review the documents making sure that the requirements and Use Cases are logically sound.

Architecture

The architecture of a software system or software architecture refers to an abstract representation of that system. Architecture is concerned with making sure the software system will meet the requirements of the product, as well as ensuring that future requirements can be addressed. The architecture step also addresses interfaces between the software system and other software products, as well as the underlying hardware or the host operating system.

Implementation, testing and documenting

Implementation is the part of the process where software engineers actually program the code for the project.

Software testing is an integral and important part of the software development process. This part of the process ensures that bugs are recognized as early as possible.

Documenting the internal design of software for the purpose of future maintenance and enhancement is done throughout development. This may also include the authoring of an API, be it external or internal.

Deployment and maintenance

Deployment starts after the code is appropriately tested, is approved for release and sold or otherwise distributed into a production environment.

Software Training and Support is important because a large percentage of software projects fail because the developers fail to realize that it doesn't matter how much time and planning a development team puts into creating software if nobody in an organization ends up using it. People are often resistant to change and avoid venturing into an unfamiliar area, so as a part of the deployment phase, it is very important to have training classes for new clients of your software.

Maintenance and enhancing software to cope with newly discovered problems or new requirements can take far more time than the initial development of the software. It may be necessary to add code that does not fit the original design to correct an unforeseen problem or it may be that a customer is requesting more functionality and code can be added to accommodate their requests. It is during this phase that customer calls come in and you see whether your testing was extensive enough to uncover the problems before customers do. If the labor cost of the maintenance phase exceeds 25% of the prior-phases' labor cost, then it is likely that the overall quality, of at least one prior phase, is poor. In that case, management should consider the option of rebuilding the system (or portions) before maintenance cost is out of control.

Bug Tracking System tools are often deployed at this stage of the process to allow development teams to interface with customer/field teams testing the software to identify any real or perceived issues. These software tools, both open source and commercially licensed, provide a customizable process to acquire, review, acknowledge, and respond to reported issues.


Right now, we're at the First Stage - Requirements Analysis:

(from [4]):

Overview

Conceptually, requirements analysis includes three types of activity:

  • Eliciting requirements: the task of communicating with customers and users to determine what their requirements are. This is sometimes also called requirements gathering.
  • Analyzing requirements: determining whether the stated requirements are unclear, incomplete, ambiguous, or contradictory, and then resolving these issues.
  • Recording requirements: Requirements might be documented in various forms, such as natural-language documents, use cases, user stories, or process specifications.

Requirements analysis can be a long and arduous process during which many delicate psychological skills are involved. New systems change the environment and relationships between people, so it is important to identify all the stakeholders, take into account all their needs and ensure they understand the implications of the new systems. Analysts can employ several techniques to elicit the requirements from the customer. Historically, this has included such things as holding interviews, or holding focus groups (more aptly named in this context as requirements workshops) and creating requirements lists. More modern techniques include prototyping, and use cases. Where necessary, the analyst will employ a combination of these methods to establish the exact requirements of the stakeholders, so that a system that meets the business needs is produced. [edit] Requirements engineering

Systematic requirements analysis is also known as requirements engineering.[3] It is sometimes referred to loosely by names such as requirements gathering, requirements capture, or requirements specification. The term requirements analysis can also be applied specifically to the analysis proper, as opposed to elicitation or documentation of the requirements, for instance.

Requirement engineering according to Laplante (2007) is "a subdiscipline of systems engineering and software engineering that is concerned with determining the goals, functions, and constraints of hardware and software systems."[4] In some life cycle models, the requirement engineering process begins with a feasibility study activity, which leads to a feasibility report. If the feasibility study suggest that the product should be developed, then requirement analysis can begin. If requirement analysis precedes feasibility studies, which may foster outside the box thinking, then feasibility should be determined before requirements are finalized.

Types of Requirements

Requirements are categorized in several ways. The following are common categorizations of requirements that relate to technical management:

Customer Requirements

Statements of fact and assumptions that define the expectations of the system in terms of mission objectives, environment, constraints, and measures of effectiveness and suitability (MOE/MOS). The customers are those that perform the eight primary functions of systems engineering, with special emphasis on the operator as the key customer. Operational requirements will define the basic need and, at a minimum, answer the questions posed in the following listing:

  • Operational distribution or deployment: Where will the system be used?
  • Mission profile or scenario: How will the system accomplish its mission objective?
  • Performance and related parameters: What are the critical system parameters to accomplish the mission?
  • Utilization environments: How are the various system components to be used?
  • Effectiveness requirements: How effective or efficient must the system be in performing its mission?
  • Operational life cycle: How long will the system be in use by the user?
  • Environment: What environments will the system be expected to operate in an effective manner?

Functional Requirements

Functional requirements explain what has to be done by identifying the necessary task, action or activity that must be accomplished. Functional requirements analysis will be used as the toplevel functions for functional analysis.

Non-functional Requirements

Non-functional requirements are requirements that specify criteria that can be used to judge the operation of a system, rather than specific behaviors.

Performance Requirements

The extent to which a mission or function must be executed; generally measured in terms of quantity, quality, coverage, timeliness or readiness. During requirements analysis, performance (how well does it have to be done) requirements will be interactively developed across all identified functions based on system life cycle factors; and characterized in terms of the degree of certainty in their estimate, the degree of criticality to system success, and their relationship to other requirements.

Design Requirements

The “build to,” “code to,” and “buy to” requirements for products and “how to execute” requirements for processes expressed in technical data packages and technical manuals.

Derived Requirements

Requirements that are implied or transformed from higher-level requirement. For example, a requirement for long range or high speed may result in a design requirement for low weight.

Allocated Requirements

A requirement that is established by dividing or otherwise allocating a high-level requirement into multiple lower-level requirements. Example: A 100-pound item that consists of two subsystems might result in weight requirements of 70 pounds and 30 pounds for the two lower-level items.[1]


Software Requirements Specification Templates and Information

The end product of a requirements analysis is a Software Requirements Specification (see [5] and [6]). Here's an example: [7]

1. Example

Here is a useful Software Design Specification Template (see [8])