Content deleted Content added
m →The concepts behind Internet-speed development method: WP:CHECKWIKI error fixes using AWB (9494) |
m cleanup (wikitables, html markup, layout, etc.) |
||
Line 4:
==Main ideas behind Internet-Speed Development==
Often one of the biggest problems in software engineering is that the requirements change quickly and the internet-speed development method was created to adapt to this situation. The idea is to combine two main standards in software engineering models namely the spiral model and the waterfall model into a new model and base a new software engineering method on this new model. The main disadvantage of the waterfall model was that is was very rigid and not very flexible when it comes to changes in requirements, while the disadvantage of the spiral model was that is was not very structured. The idea behind internet-speed development is that the combination of these models will result in a method which does not have these disadvantages and is a better method to use in situations where requirements can change rapidly, but the project has to be executed in a structured way.
==Goal of the method==
The goal of the internet-speed development method is to allow software developers to perform a project in a structured way, but still be able to adapt to the needs of the customer. It aims to deliver a software product in a short time through intensive development. The method provides a means to deliver a fully implemented system and also has ways to determine progress in a project through the use of milestones. One of the main versions of this method is created by Microsoft and is called the [[Microsoft Solutions Framework]].
==The concepts behind Internet-speed development method==
The first concept that is very important to internet-speed development is the creation of a vision and [[scope (project management)]]. What this means is that in the beginning of the project a global definition of the system is created which explains what the system aims to be and what is within the scope and what is not. This is one of the fundamental steps as it gives the developers some guidelines as to what the system will be without freezing any requirements. The scope can be documented in a [[vision statement]].
Another very important concept within this method is scope management. The scope needs to be managed throughout the project to prevent [[scope creep]]ing which results in delays. The scope will be determined early and changes to the scope (like adding additional features which were at first considered beyond the scope of the project) will be evaluated and either accepted or rejected. Changes in the scope can be made but this will always be affected by trade offs between features, resources and time.
Line 18 ⟶ 17:
Internet-speed development also focuses on using one fixed framework architecture from which the product is build and relies heavily on tools to increase the development speed.
Another basic concept of internet-speed development is that it also focuses on using small teams. The idea is that all projects can be divided into smaller activities which often can be done parallel. Smaller teams can often be more focused on their task and it is easier to determine accountability and monitor progress within the project.
Line 26:
==The phases of Internet-Speed Development ==
The model behind this method looks like this:
[[File:PhaseModel.jpg]]
''Figure 1: Phase model''
This model shows the five basic phases of the method. These phases will be explained in the following sections of this entry. The phases are: Envisioning, Planning, Developing, Stabilizing and Deploying. After this cycle has been completed a version of the system is ready and a new cycle begins to create a new version. The phases are explained in the following sections and are shown through a [[meta-modeling]] technique. More details about multiplicities and concepts in a project context can be seen in the overall data model later on.
===Envisioning phase===
The envisioning phase can be modeled as followed:
[[File:Envisioning.jpg]]
''Figure 2: Envisioning phase process/data model''
{| class="wikitable"
|-
! Activity
! Definition (source)
|-
|Analyze requirements
|During the envisioning phase, business requirements must be identified and analyzed.
“These are refined more rigorously during the planning phase.”
(MSF Process model)<ref name="ReferenceA">Microsoft Solutions White Paper June 2002</ref>
|-
| Define Goals and Constraints
|“Envisioning, by creating a high-level view of the project’s goals and constraints.”
(MSF Process model)<ref name="ReferenceA"/>
|-
|Form Team
| Formation of the core team.
|-
| Create Vision/scope
| “The preparation and delivery of a vision/scope document.”
(MSF Process model)<ref name="ReferenceA"/>
|-
| Create Risk assessment
| “During the envisioning phase, the team prepares a risk document and presents the top risks.”
(MSF Process model)<ref name="ReferenceA"/>
|}
''Table 1: Envisioning activities''
The basic activities performed in the envisioning phase are analyzing the requirements, forming the team for the project, determining the risks and the scope of the project. From the requirements and the goals of the project a Vision/Scope document is created. This document describes what the product is to be when it is delivered. It does not contain very detailed functionalities of the product.
{| class="wikitable"
|-
! Concept
! Definition (source)
|-
| VISION/SCOPE DOCUMENT
Line 139 ⟶ 121:
===Planning Phase===
[[
''Figure 3: Planning phase process/data model''
{| class="wikitable"
|-
! colspan=2 | Activity
! Definition (source)
|- VALIGN=TOP
| colspan=2 | Define Requirements
| Early in the planning phase, the team analyzes and documents
requirements in a list or tool. Requirements fall into four broad
categories: business requirements, user requirements, operational
requirements, and system requirements (those of the solution
itself).”
(MSF Process model)<ref name="ReferenceA"/>
|- VALIGN=TOP
| colspan=2 | Trace Requirements to Features
| “As the team moves on to design the solution and create the functional specifications, it is important to maintain ''traceability'' between requirements and features. Traceability does not have to be on a one to one basis. Maintaining traceability serves as one way to check the correctness of design and to verify that the design meets the goals and requirements of the solution.”
(MSF Process model<ref name="ReferenceA"/>
|- VALIGN=TOP
| colspan=2 | Define Functional Specification
| “The team prepares the functional specification.”
(MSF Process model<ref name="ReferenceA"/>
|- VALIGN=TOP
| rowspan=4 | Create Planning
| Estimate Risks
| Team creates a risk estimation.
|- VALIGN=TOP
| Estimate Costs
| Team creates a costs estimation.
|- VALIGN=TOP
| Create work plans
| Team creates work plans.
|- VALIGN=TOP
|Create Schedules
|Team creates schedules.
|- VALIGN=TOP
| rowspan=5 | Create Design
|Create Use-Case Model
| “This begins with a systematic analysis of ''user profiles''
(also called “personas”) which describe various types of
users and their job functions (operations staff are users too).
Much of this is often done during the envisioning phase. These are
broken into a series of ''usage scenarios'', where a particular
type of user is attempting to complete a type of activity, such as
front desk registration in a hotel or administering user passwords
for a system administrator. Finally, each usage scenario is broken
into a specific sequence of tasks, known as ''use cases'',
which the user performs to complete that activity. This is called
“story-boarding.””
(MSF Process model<ref name="ReferenceA"/>
|- VALIGN=TOP
|Create Conceptual Design
|Creation of a conceptual design.
|- VALIGN=TOP
|Create Logical Design
|Creation of a logical design.
|- VALIGN=TOP
|Create Physical Design
|Creation of a physical design.
|- VALIGN=TOP
|Create Architecture
|Creation of the architecture for the product.
|}
''Table 3: Planning activities''
In the planning phase a functional specification is created from the requirements. Features selected are included in this specification (a [[MoSCoW Method]] is often used for the features so they can be prioritized more easily). Also the basic design and planning are created in this phase. The design however is in this phase not frozen as changes may be made in the development phase.
{| class="wikitable"
|-
! Concept
! Definition (source)
|- VALIGN=TOP
| REQUIREMENTS LIST
| Documentation
of requirements in a list or tool.”
(MSF Process model<ref name="ReferenceA"/>
|
RISK MANAGEMENT PLAN
| Document
on how the team plans to implement the risk management process
within the context of the project.”
(MSF Risk Management Discipline<ref name="ReferenceB"/> )
|- VALIGN=TOP
| MASTER PROJECT PLAN
| All
plans are synchronized and presented together as the master
project plan.”
(MSF Process model<ref name="ReferenceA"/>
|- VALIGN=TOP
| WORKPLANS
| A plan or plans for the deliverables that pertain to the role and
participates in team planning sessions.”
(MSF
|- VALIGN=TOP
| COST ESTIMATES
| An estimation of the costs of the project.
|- VALIGN=TOP
| SCHEDULES
| Time estimates and schedules for Deliverables.”
(MSF Process model<ref name="ReferenceA"/>
|- VALIGN=TOP
| MASTER PROJECT SCHEDULE
| The
various schedules are then synchronized and integrated into a
master project schedule.”
(MSF Process model<ref name="ReferenceA"/>
|- VALIGN=TOP
| FUNCTIONAL SPECIFICATION
| The
functional specification describes in detail how each feature is
to look and behave. It also describes the architecture and the
design for all the features.”
(MSF Process model<ref name="ReferenceA"/>
|}
''Table 4: Concepts in the planning phase''
===Development phase===
[[
''Figure 4: Developing phase process/data model''
{| class="wikitable"
|-
|-
| Develop Features
| Building of solution components (documentation as well as code).”
(MSF Process model)
Also includes testing after the daily build, bug fixing and evaluating the features.
|-
Line 593 ⟶ 264:
|-
| Finalize Scope
| At this milestone, all features are complete and the solution is ready for external testing and stabilization.”
(MSF Process model)
|-
| Develop Infrastructure
| The infrastructure is developed.”
(MSF Process model)
|}
''Table 5: Developing activities''
The most important activity in the developing phase is the development of the features. Besides the implementation of these features the scope is also finalized in this phase. During development new features may be added to the product, but once the scope is finalized the features become frozen and ready for testing and stabilizing. The infrastructure is also developed in this phase which means that network structures are identified and servers like for example a database server are defined.
{| class="wikitable"
|-
! Concept
! Definition (source)
|-
| INSTALLATION SCRIPTS AND CONFIGURATION SETTINGS FOR DEPLOYMENT
Line 630 ⟶ 298:
| FUNCTIONAL SPECIFICATION
| The functional specification describes in detail how each feature is to look and behave. It also describes the architecture and the design for all the features.”
(MSF Process model)<ref name="ReferenceA"/>
|-
| SOURCE CODE AND EXECUTABLES
Line 640 ⟶ 307:
|-
| EXECUTABLE
| The executable created by source code.
|}
''Table 5: Concepts in the developing phase''
===stabilization phase===
[[
''Figure 5: Stabilization phase process/data model''
{| class="wikitable"
|-
|-
| Testing
| Testing during this phase emphasizes usage and operation under realistic environmental conditions.“
(MSF Process model)<ref name="ReferenceA"/>
|-
| Resolve Bugs
| The team focuses on resolving and triaging (prioritizing) bugs and preparing the solution for release.”
(MSF Process model)<ref name="ReferenceA"/>
|-
| Deploy Pilot
| Once a build has been deemed stable enough to be a release candidate, the solution is deployed to a pilot group.”
(MSF Process model)<ref name="ReferenceA"/>
|-
| Review
| Once reviewed and approved, the solution is ready for full deployment to the live production environment.”
(MSF Process model)<ref name="ReferenceA"/>
|}
''Table 6: Stabilization activities''
The main activities are the testing and resolving of bugs. Once a build version is considered stable enough for a pilot a pilot version is created and deployed. From this pilot it will either go back into the testing/stabilizing loop or it will be approved and reviewed.
{| class="wikitable"
|-
|-
| TEST RESULTS AND TESTING TOOLS
Line 712 ⟶ 372:
|}
''Table 7: Concepts in Stabilization phase''
===deployment phase===
[[
''Figure 6: Deployment phase process/data model''
{| class="wikitable"
|-
! Activity
! Definition (source)
|-
| Deploy the Core Components
Line 741 ⟶ 398:
|-
| Review the project
| Final review of the project.
|}
''Table 8: Deploying activities''
The main activity in the deploying phase is the installation of the infrastructure needed to run the product (deployment of servers etc.). Also the documents are finalized and transferred to the operations and support department, a knowledge base is created and the product and project are reviewed by the customer (if applicable) and the project team.
{| class="wikitable"
|-
|-
| PROCEDURES AND PROCESSES
Line 792 ⟶ 448:
|}
''Table 9: Concepts in Deploying phase''
===Overall data model===
[[
''Figure 7: Overall data model''
This data model shows all the concepts with multiplicities and relations in a full project context.
==Tools for use with Internet-Speed Development==
* Drawing tools (examples: Microsoft Visio, Rational Rose, [[Dia (software)|Dia]]) For making diagrams.
| |||