Doddy Christiana Saputra

A value-up approach requires an explicit architecture, but it may emerge from the implementation. This creates an apparent contradiction. On one hand, you must consider all the QoS and deployment constraints in the context of the scenarios. On the other hand, value-up considers running tested code to be the best measure of system progress, and the act of developing is the act of designing, albeit at a very detailed level. It is exactly the act of development, in small fixed-scope iterations, that enables design to emerge from the implementation.

Baseline Architecture

A baseline architecture is a executable skeletal application designed expressly to mitigate technical risk and provide a solid, stable basis for project iterations. Some agile developers refer to this as “iteration zero” when platform infrastructure components are installed and a “thin vertical slice” of the system is built, exercising a very simple scenario from end to end (for example, from the user interface to the database). The goal here is to flush out and validate the project’s architecturally significant mechanisms unambiguously. Removing ambiguity mandates that the baseline architecture be executable.As an example, consider a popular application stylea web application using a relational database. A number of fundamental questions need to be answered early to determine the best fit based on good citizenship and all the perspectives of the advocacy groups , Should this application be bought or built? Should the application be a smart client or a web application? If it is a web application, what processing should be done on the client using technologies such as Asynchronous Java Script and XML (AJAX), and what processing should be done on the server? As for persistence (assuming a relational database), what are the organizational standards for the choice of a relational database? Should a new database instance be created, or should tables be added to an existing database instance? What is the source of reference data for this application? How does this application integrate with other applications in the enterprise? How many business transactions per day must this system be able to execute to support the project’s economic justification? Will this application be deployed, operated, and maintained in a corporate datacenter? If so, what are the technical constraints of the datacenter? As these fundamental kinds of decisions are made early in the project lifecycle, they result in constraints that guide and stabilize the project under development.There is a delicate balance to strike. As you work through these technical issues, try to defer decisions to the “last responsible moment.” The last responsible moment, however, will vary depending on project complexity. Often, you will let detailed design issues, such as interfaces and method factoring, evolve from implementation. In more complex projects with many dependencies, you may need to pin down interfaces and mitigate architecturally significant risks early to avoid later rework. Then, within the agreed policy, build an executable baseline that implements these high-level design decisions so that they can become architectural constraints on the project.Defining this baseline early benefits developers by providing stable platform infrastructure components and protocols for application development. Defining these constraints early also enables predictability and planning for other stakeholders. For example, Release/Operations can plan for the deployment and management of the application in production and can ensure datacenter readiness. Product management in the line-of-business can create marketing plans designed to attract levels of usage at transaction rates the system can support. Business analysts can design business process monitoring reports to analyze the application’s return on investment, which will feed planning for the next version.
Enterprise architects can design and implement reusable services across the enterprise, migrating toward an enterprise-level SOA. Defining these constraints early enables a stable, predictable basis for multiple stakeholders.

Validate Architectural Decisions

This process is not just top-down. You need to validate these constraints bottom-up by building an executable skeletal architecture. VSTS enables you to model your “asis” datacenter using the Logical Datacenter Designer and your “to-be” application using the System and Application Designers and then to run a validation report to identify conflicts between the two. Then your System and Application models can be used to generate skeletal code that can become part of your executable baseline.Doing so provides many benefits. The running code is unambiguousshould areas of design seem unclear, the source code can be consulted. The running code can be performance tested to validate initial transaction rates of the system. System settings can be verified against datacenter policies to identify potential conflicts. Also, building an executable system forces lower-level design decisions to become explicit, further refining the baseline.

Refining the Baseline

As you build out the skeletal architecture to run end-to-end, you are forced to consider lower-level design decisions. How will you structure your application logic? What is your data access approach? Will you deploy the business logic on the same server as the web server, or will you deploy them on separate application servers? What authentication and authorization mechanisms will you use? What protocols will you use between servers?Don’t try to address all the concerns yet. Choose the areas of highest technical risk to validate and let the other decisions emerge through implementation. Think about building the simplest skeletal application that will meet your constraints, mitigate technical risks, and still provide a sound, stable basis for development iterations.

knowledge and experience of others who may have also solved similar problems before and captured the learning in patterns.Patterns also give you a language with which you can concisely describe solutions, mitigate risk by reusing known good designs, and enable future maintenance and reuse of your work.

Reference Architectures

In many cases, you can use a reference architecture as a baseline. For example, Microsoft has created a reference application called Applied Integration Baseline (AIB), which uses a pattern-based approach to build an executable baseline , This application ships with more than twelve Visual Studio projects and is based on ASP.NET, BizTalk Server, SQL Server, Host Integration Server, and VSTS.

The Application Integration Baseline provides an interactive “Narrator” to visualize the baseline architecture. The visual models include VSTS Application Designer and Logical Datacenter Designer models as well as a pattern-based description of the system. Here the narrator is illuminating a scenario one step at a time by rendering each step on the Application Designer diagram.

A typical problem that most organizations face is the complexity of moving a system as designed into a datacenter as configured. The development and operations teams typically have different vocabulary, different staffs, and different physical locations (sometimes on different continents or in different companies). The information flow between development and operations can be very dissatisfying, often inaccurate and incomplete.Particularly with distributed systems, there are many parts to deploy on many servers, each with its own configuration requirements. For example, applications that run in test environments don’t run in production environments because the applications violate policies that developers were not aware of. In this situation, architectural design changes are sometimes required to bring applications into conformance, or conversely, applications need to make requirements of the datacenter, such as specific versions or service packs. These operational requirements may conflict with the existing deployments of other applications. The consequence of these communication mismatches may be a delay of weeks or months between the time that architects, developers, and testers announce that an application is ready to deploy and the readiness of operations to actually deploy it.In the value-up approach of embracing change and enabling business agility, these delays are a huge barrier. VSTS starts to remove these disconnects by enabling Design for Operations. The principle is simple. Rather than waiting until an application is implemented to attempt deployment, VSTS tests the deployability of the application during its design. The solution architect and infrastructure architect can then resolve any incompatibility between the application requirements and the datacenter constraints well ahead of actual deployment and significantly reduce the bake time needed for successful deployment.Design for Operations is made possible by the System Definition Model (SDM):At the heart of SDM is the notion of a system. In its most basic form, a system is an independently deployable configuration of resources. For software systems, resources are ultimately directories and files, such as binaries, XML files, configuration files, SQL script files, and so on. For hardware systems, such as graphics systems, motherboards, network interface cards and power supplies, resources might include the boards, processor chips, memory chips, fans, and other lower-level components.If a system enables access to its resources, or if its resources access services offered by resources in other systems, it exposes those resources via endpoints. For example, a motherboard might provide an IDE endpoint for peripherals; web service endpoints provide a means for an application to expose or consume web services; HTTP endpoints provide a means for a server to enable access using the HTTP protocol.The SDM is visualized on the Deployment Designer . It marries the application design (typically from the solution architect) with the logical datacenter design (from the infrastructure architect). Directly on this diagram, you can validate the architecturethat is, you can determine whether the application as designed will deploy in the datacenter as configured. Any exceptions appear directly as warnings with glyphs on the diagram as needed

Validation of the Deployment Designer can identify conflicts between the application as designed and the datacenter as configured. In this example, the application requires Windows Server 2003, but it is intended for deployment on a server with an earlier OS

Cheers,

Doddy Ch Saputra,MCPD(Ent),MCTS,MCT

Consideration - What Software Is Worth Building?To overcome the gap, you must recognize that software engineering is not like other engineering. When you build a bridge, road, or house, for example, you can safely study hundreds of very similar examples. Indeed, most of the time, economics dictate that you build the current one almost exactly like the last to take the risk out of the project.With software, if someone has built a system just like you need, or close to what you need, then chances are you can license it commercially (or even find it as freeware). No sane business is going to spend money on building software that it can buy more economically. With thousands of software products available for commercial license, it is almost always cheaper to buy. Because the decision to build software must be based on sound return on investment and risk analysis, the software projects that get built will almost invariably be those that are not available commercially.

This business context has a profound effect on the nature of software projects. It means that software projects that are easy and low risk, because they’ve been done before, don’t get funded. The only new software development projects undertaken are those that haven’t been done before or those whose predecessors are not publicly available. This business reality, more than any other factor, is what makes software development so hard and risky, which makes attention to process so important.

Quality of Service MindsetMSF describes a QoS mindset as follows:The idea is that qualities of service such as performance and security should not be considered late in the project but throughout it. When ignored, these qualities of service are ultimately consumer dissatisfiers.

Architectural design needs to reflect this QoS mindset. Often the architect is the team member most able to consider the implications of QoS requirements, implicit or explicit. In turn, the decisions with the greatest impact on QoS are typically made during design.

cheers,

Doddy Ch Saputra,MCPD(Ent),MCTS,MCT

Hi folks,

Nice to see you again in the second part of the most frequently ask which be asked to me, okay in this part I will explain a case-2  with company deploys a Team Foundation Server (TFS) server.

To enhance network performance we deploy Team Foundation Server Proxy to each remote location.we need to configure the cache for Team Foundation Server Proxy.

We also need to ensure that users can use Team Foundation Server Proxy at the remote locations.

Which two actions should we perform are :

1.     Configure Microsoft Visual Studio Team System 2008 for the users at each remote location to help them use

the deployed Team Foundation Server Proxy, we need to configure this action because all the remote site will grab all the credential authority from each part of the TFS.

2.     Configure Team Foundation Server Proxy to enable source code caching by adding the

<Uri>http://TFS:8080/VersionControl</Uri> element to the proxy.config file. Due to the QOS need running in charged in remote site then we need proxy mode for running the TFS in each remote site and then we need to put the setting of the URL setting of the proxy in each remote site.

If we have done all the necessary things above, then the requirement already being accomplished.

Okay Thank you and see you  in my next session of TFS /VSTS trouble shooting .

See you …GBU

Most of Team foundation administrator are face the problem of their initial design for their environment, but i often suggest to them to analyst based on the requirement of their development environment itself, the non functional requirement are the critical success factor which really need to be considered for their deployment strategy, why ?? because it will define the quality of the service of he development environment.

Okay Let’s take a look a sample case that could be taken :

Case 1 :

There are some requirement from our development environment and we have defines the point of the QOS that we need to be achieved :

·         Integrate the Team Foundation Server (TFS) solution with the Active Directory domain.

·         Implement the correct version of IIS.

·         Maintain cached information at the remote site

So from that point above  , we need some prior action should be taken :

1.     Install IIS 6.0. in the Application Server Role dialog box, and then select the Enable ASP.NET

check box, sometime the admin under estimate this action but we need take this action as an our first priority task, which is IIS will become the Hosting Engine of the TFS it self which is become your sharepoint services  hosting and enabled the ASPNET for utilize the capability of web based engine from dotnet technology it self.

2.     Create a Windows domain user account for Team Foundation Server Proxy and define the user account as the service identity, this action is really need for the QOS prerequisite because the user account which already registered in the active directory will be recognized in active directory domain in this case we need to registered the user in domain controller server user account or if not we could using domain joint server with fully trusted connection to the active domain server.

Folks, I will continue to next case in next parts…

Hi folks,

Microsoft® Visual Studio® 2008 Team Foundation Server introduces a number of new features and capabilities. The primary changes have been:

                        Administration, Operations & Setup. Installation has been simplified to reduce setup time and improved to support more deployment scenarios.

                        Build. Build includes Continuous Integration, scheduled builds, and build queuing solutions out of the box. Build management and extensibility has been simplified with more functionality available from the UI.

                        Version Control. Version control includes much better support for offline work and has improved performance.

                        Work Item Tracking. Work item tracking includes an improved query builder and improved support for work item attachments.

These product changes are listed and briefly described below, followed by a table explaining how the changes will impact the guidance in this guide. Use this chapter to aid in your Microsoft Visual Studio Team Foundation Server upgrade planning.

Administration, Operations & Setup

                        Simplified installation –Installation is made easier and quicker compared to Visual Studio 2005 TFS. Improvements include the elimination of the separate data-tier installation as well as the elimination of the domain account requirement. Team Foundation Server 2008 supports built-in machine accounts (such as Network Service) wherever possible.

Read the rest of this entry »

Hi Folks,

Many friends developer of mine, have asked to me to rectify how the easiest way to populate the report for showing the development status on their project.

As we know that the iteration of the project always running from the beginning until the end of the project and controlled by the project manager and during at that time for example in the midst of the project, some time our Top level management such as CTO (Chief Technology Officer) asking about the progress of our project or our management team wants to evaluate the project costs and schedules for each developer.

The management team uses Microsoft Project to view the work-item fields for each project task.

The project tasks contain custom properties that assist in cost and schedule calculation.

We need to ensure that the work-item fields populate the custom properties in the project tasks.

So the best easiest way to populate the mapping field into our progress report in your visual studio team system or your Team foundation server is running the tools we called by TFSFIELDMAPPING.EXE.

Those tools are running under command tools utility and after you execute and follow the correct instruction then the mapping justification will be rebuilt from the latest status of your project.

Okay Folks,

See you again .

Hi Digger, see you again in my journal,

Team Foundation Server does not support bulk editing of work items. Instead, we must edit each work item individually. If we need to modify a large number of work items in a short period of time—for example, during a triage meeting—consider using Microsoft Office Excel® to ease the task. Work items can be exported from TFS to Excel, modified, and then imported back into TFS to retain any edits that we made.

Here are the following step to create a work item list in Excel and edit it  :

  Read the rest of this entry »

This How To article shows us how to build an appropriate source control folder structure that you can use with most common project types. The folder structure presented in this article uses three top level folders:

                        Main. This is the main root folder that acts as a container folder for your main source tree, together with accompanying project artifacts such as design documentation, scripts, and test cases. The Main folder also contains your Visual Studio Solution (.sln) files.

                        Development. This is an optional root-level folder that you can use if you need to create isolation for features or teams development. This folder is created by branching from Main.

Read the rest of this entry »

This How To article shows us how to build a source control folder structure that is appropriate for Windows Forms applications. Because Windows Forms projects often include additional class and control libraries, a structure is required to accommodate these as well. Folders in which to maintain your Windows Forms projects are located beneath a /Main/Source top-level structure. This enables you to easily use additional Development and Releases folders if you need to create branches for isolated development and for release maintenance. For more information about creating this top level folder structure, see “How To: Structure Your Source Control Folders in Visual Studio team Foundation Server.”

  Read the rest of this entry »

This How To article shows us how to build a source control folder structure that is appropriate for ASP.NET Web applications. Because ASP.NET Web projects often include additional class libraries, a structure is required to accommodate these as well. Folders in which to maintain your ASP.NET Web projects are located beneath a /Main/Source top-level structure in source control. This structure enables you to easily use additional Development and Releases folders if you need to create branches for isolated development and for release maintenance. For more information about creating this top-level folder structure, see “How To: Structure Your Source Control Folders in Visual Studio

  Read the rest of this entry »

Many friends of mine have asked to me to explain the features in VSTS Rosario edition, so i would like to explain view things about this edition version, in this version leverage the existing or previous version in the context of ALM ( Application Life cycle Management ), here are the following points below :
·    Development Scheduling and Tracking
Teams will be able to communicate tasks and progess more effectively through work item tracking, including being able to create parent-child relationships between work items, identifying task dependancies, and tracking progress through readily available spreadsheets and reports.
·    Requirements Test Coverage and Manual Testing
Being able to see the relationship between test cases and software requirements gives the test team an opportunity to identify missing test cases early, to identify which test cases are failing for a particular requirement, and to recognize trends in failing test cases. Running automated and manual test cases, testers can find and report bugs. Using the new manual test runner, they will be able to include more bug data than was previously available.
·    Dependency Management
Developers will be able to easily identify cross-task dependancies, enabling other developers on the team to prioritize their work .
Development Scheduling and Tracking
Visual Studio Team System code name “Rosario” improves the way you schedule and manage work items and track progress. Either through integration with Microsoft Excel, or through Visual Studio Team Explorer, you can enter, edit, and track the progress of work items. With this CTP release you can link work items in a parent-child relationship, which enables you to track the progress of requirements from feature definition through to task completion.
With this release the new capabilities include:
·    Improved integration with Excel
·    Linking work items with parent-child relationships
·    Progress tracking based on parent-child relationships
Requirements Test Coverage and Manual Testing
This CTP release enables you to view business requirements based on their existing test coverage, which enables you to identify gaps in the current test plan. Once you have identified the business requirements that are lacking test coverage, you can create test cases that link to these requirements.
The addition of a standalone manual test runner enables you to run tests outside of the IDE. In the event that you find a bug , you can record more data than was previously available. You can use the manual test runner to download a test run from a Team Foundation Server,  publish test results, and open bugs with detailed data including screenshots, automatically collected system information, reproduction steps, and a video screen capture of the steps taken to find the bug.
With this release the new capabilities include:
·    Test coverage queries showing requirements missing tests
·    Manual test runner

• Test cases
• Run test cases stored on a Team Foundation Server
• Publish the results of a test case run
• Bugs
• File a bug
• Automatic collection of system information
• Ability to include screenshots
• Logging of reproduction steps
• Video screen capture of events triggering bug
• Dependency Management

Cross-team communication is essential to any project and the addition of the work item dependency feature is built to support this. With this CTP release, team members can now identify work items that their work items are dependant on, enabling the team to identify the priority of tasks based on these dependancies. Any team member can view a list of work items that are dependant on his assignments by running a work item query. These work item dependancies are also trackable through reports.
With this release the new capabilities include:
·    Work item dependency identification
·    Work item dependency tracking and reporting

Hi folks ,

This is the second part on how to migrate from our Visual source safe into Team foundation server for your agile source control environment, i will repeat the previous step last time which was going to the 3rd step ,

Step 3 – Analyze Your Projects in VSS

In this step, you determine which projects you want to migrate and then run the TFS command-line tool VSSConverter.exe to analyze the VSS database for any potential issues that might cause migration problems.

1. Create an Extensible Markup Language (XML) settings file (named for example, ConversionSettings.xml) as follows:

<?xml version=”1.0″ encoding=”utf-8″?>

<SourceControlConverter>

<ConverterSpecificSetting>

<Source name=”VSS”>

<VSSDatabase name=”c:\VSSDatabase”>

</VSSDatabase>

</Source>

<ProjectMap>

<Project Source=”$/MyFirstProject”></Project>

<Project Source=”$/MySecondProject”></Project>

</ProjectMap>

</ConverterSpecificSetting>

</SourceControlConverter>

In the above example, MyFirstProject and MySecondProject represent the names of the project folders in VSS that you want to migrate. To migrate an entire VSS database, use <Project Source=”$/”></Project>.

  Read the rest of this entry »

Hi Folks,

To fulfil the needs from many friends developer which they had faced the problem of how to migrate their development source code from the previous source control in this case visual studio source safe 2005 into more wider environment of ALM integrated tools development Team Foundation Server.

Team Foundation Server provides tools to help us migrate existing source maintained in a Visual Source Safe (VSS) database to TFS source control. TFS provides a VSSConverter tool that allows you to migrate files, folders, version history, labels, and user information. Using the VSSConverter tool is a two-stage process; first you use the tool to analyze your existing VSS database to identify potential problems, and then you use it to actually perform the migration.

  Read the rest of this entry »

Hallo,

Another kind of a methology for anayzing and designing development process is MSF for CMII, i’m not emphasize to much about this methodology, but for at least i’ll try to share the idea of this methodology, okay …

The Software Engineering Institute’s (SEI) Capability Maturity Model Integration (CMMI4) provides five levels at which an organization’s.process maturity can be measured, and it is often used to guide processimprovement across a project or an entire organization.

In theory,

you can select MSF for CMMI when creating your Team Projectand then simply follow the Process Guidance to become ready for level

three certification while having a clear way to reach level five.

However, inpractice, your team will have to do a lot more than just follow a set ofinstructions in order to achieve CMMI certification and produce great software.You can get some idea of the amount of work involved in using theMSF for CMMI framework by reading its Process Guidance and looking at

the documents it creates in your Team Project’s document folder.

This development process, as you might imagine, is completely prescribed andthere is almost no scope for variation, which makes it an unattractive optionfor a team that wants a design process. 

If you are working for a defense contractor or are involved with safetycriticalprojects, your team may have no option but to obtain CMMI certification,

in which case MSF for CMMI could be a good choice.

However, teams working on other types of projects might want to look for alternativeframeworks. Given the amount of management expected for peopleusing the MSF for CMMI framework, it is difficult to see how its use couldbe justified in a small or even medium-size teamprobably in next session i’ll talking much in practises by using TFS.

cheers,

Doddy Ch Saputra, MCPD,MCITP,MCTS

Hi Geeks,

How are you, well we met again in this session which talking about a part of designing and analyzing development. Currently we will discuss about RUP (Rational Unified Process) , so let’s rock and roll

RUP has reflects the experiences of over a decade of software development from a variety of companies and thought leaders applying object-oriented and iterative technique.

With respects to object oriented , the most roots of the process include Jacobson objector process, which introduced the use-case technique for requirement expression and leveraged component and object –oriented thinking.  We could know the RUP by these characters :

1. RUP provides a full lifecycle approach covering a series of product lifecycle phases called inception, elaboration, construction, and transition.
2. RUP Provides a software development method and a set software engineering practices that cover the majority of software development disciplines
3. RUP iterative. Within each phase, the project undergoes multiple iterations ; the nature of each is determined in part by the life cyle phase. Early iterations build the business case and the requirements and architectural baseline. Later iterations focus on implementation and transition to the development .
4. RUP is incremental; each iteration builds on the functionality of the prior iteration; the software application evolves in this fashion with the benefit of regular and continues feedback. 

So let’s take a look the model of RUP :

From those model above , we could know two axis, and first is Discipline axis, “…this axis elements describes the software disciplines that are necessary to achieve a quality result.These include requirements,analysis and design,implementation,test,deployment,configuration and change management and project management…”

for example :

• In elaboration,iterations will have a heavier focus on requirements,analysis and design than they do in implementation and test.
• In Project management discipline exists to stitch the other discipline together in a way that produces demonstrable results at the end of each iteration.                     

Finally let’s see another axis of those model :

   I.     Inception Iterations

·    Plan and prepare the business case. Establish the project software scope and boundary conditions, Including an operational vision and acceptance criteria.

·    Define the critical uses case of the system

·    Demonstrate at least one candidate architecture against the primary scenarios.

·    Estimates the overall cost and schedule for the entire project

·    Estimate potential risks especially time,human and ofcourse money

·    Synthesize a candidate of architecture, evaluating trade-offs in design and in make/buy/reuse so that cost,schedule and resources can be estimated.

·    Prepare the environment for the project,selecting tools and deciding which parts of the process to modify.    II.      Elaboration Iterations 

• Address architecturally significant risks of the project and implement a baseline architecture to address them.
• Produce exploratory, throwaway prototypes to mitigate critical risks.
• Demonstrate that the architecture will support the requirement of the system.
• Refine the vision of the basis of new information obtained during the phase.
• Create initial iteration plans and release plans for the construction phase
• Refine the development  case and put the development environment in place
• Refine the architecture and select components.   

  III  .  Construction Iterations

• Iteratively and incrementally develop a complete product that is ready to transitions to its user community.
• Complete the analysis,design,development and testing of all required functionality in each iteration.·Minimize development costs by optimizing resources and avoiding unnecessary scrap and rework.·Achieve adequate quality as rapidly as practical
• Decide if the software ,the sites and the users are all ready for the application to be deployed.
• Complete component development and testing against the define evaluate criteria.
•  Assess product releases against acceptance criteria for the vision. IV.  Transition Iteration

• Test early iteration and releases to validate the new system against user expectation
• Finalize end user support material; train users and maintainers.
• Roll-out to the marketing ,distribution and sales forces
• Finalize deployment – specific engineering such as cutover, commercial packaging, production,sales roll-out and field personal training.
• Complete tuning activities such as bug fixing,performance and usability enhancement .
• Assess the deployement baselines against the complete vision and the  acceptance criteria for the product.
• ·Execute deployment plan.

So, Finally just try to understand the each axis and the relationship of every point mapping inorder we could get the essential RUP as another kind of agile methodology.

cheers,

Doddy Ch Saputra,MCPD,MCITP,MCTS 

Hi Geeks,

Today i’ll show you a little bit of scrum methology that we can use to define the analyzing and requirement process of our SDLC. 

The pioneer of scrum Jeff Sutherland and Ken Schwarber , they formulated the scrum which is

 “…a lightweight agile project  management method that is enjoying widespread adoption and effective use…”

A view characteristic or the elements of Scrum methodology are :

1. Small, cross-functionality teams work closely together in an open environment to produce incremental releases of a product in 30-day increments, or sprint.·    Teams are self –directed and empowered to meet the objectives of the sprints.
2. Team work is facilitated by a scum master role who does not direct technically activity but eliminates impediments and reinforces the core discipline of scrum.
3. Work is organized via a product backlog,which is reprioritized for each sprint.               Based on the characteristic above then we could move to the next implementation if we choose        the scrum  method   as follow :
4. Cross-Funtionality and collated teams of 8 or fewer team members develop software in sprints.
5. Sprints are iterations of a fixed 30 day duration.Each sprints delivers incremental ,tested functionality of value to the user.
6. Work within a sprint is fixed. Once the scope of a sprint is committed, no additional functionality can be added except by the development team.
7. The Scrum master role  mentor and manage the self organizing and self managing teams that responsible for delivery of successful outcomes at each sprint.
8. All work to be done is carried as Product Backlog, which includes requirements to be delivered, defect workload, as well as infrastructure and design activities.
9. The product Backlog is developed, managed ,and prioritized by the product owner, who is an integral member of the team and who has the primary responsibility of interfacing with external customers.
10. A daily 15 minutes stand up meeting or “Daily scrum” is a primary communicated method.
11. Scrum focuses heavily on time boxing. Sprints, stand-up meetings, release review meetings, and like are all completed in prescribed times.

Scrum allow requirements, architecture and design to emerge over the course of the project   So, let’s take a look more deep  and dive,by using the figure that we could describe in empirical model like this :

Product Backlog –> provides input to the define/build/test process

The Evaluation Activities –> provides an objective measure whether the code delivers the intended result (Passes all tests meets objectives criteria) –> So the decision maker in evaluation will define the next item on the backlog  which will always be addressed. If not, the software is reworked immediately until it meets the objective of the requirement.The practically framework of scrum iteration could  be generated like this :
  from the principle of scrum and the activities figure above , we have a little bit clear of scrum methodology . So , have a nice development and see you again.

cheers,

Doddy Ch Saputra, MCPD,MCITP,MCTS

The Essential Of Agile Extreme Programming 

As We known before  that from Fowler,Gamma,Cunningham had defined the definition of Exteme programming which has the meaning is “..a lightweight methodology for small to medium-size teams developing software in the face of vague or rapidly changing requirements…” and furthermore XP has a view characteristics which are :

• A team of 5-10 programmers work at one location with costumer representation on site.
• Development occurs in frequent builds or iterations, each of which is releasable and delivers incremental functionality.
• Requirements are specified as stories, each a chunk of new functionality the user requires.
•  Programmers work in pairs, follow strict coding standards, and do their own unit testing.
• Requirements, architecture, and design emerge over the course of the project.

             So , let’s take a look the model of extreme programming process :

From that point view above we could follow the process of XP like this point :

1. From the left side of the graphic model ,we can see two things that drive release planning and development .
2. User stories represent functionality that is to be implemented in the course of the release.
3. Architectural spikes are any work that the team needs to execute in order to lay in some architectural foundation, to explore a potential refactoring, or to look at new technology that may need to be included in the release. These inputs drive the release planning session.
4. The outcome of the release session is an iteration plan defining a set of iterations intended to accomplish the release.
5. To the right , and integral to the iteration, are the ever-present acceptance tests, which are typically written by the customer  and serve to the test the functionality implemented against the user stories.
6. Finally, the result of all the process is a series of small releases that rapidly evolve to address the customer problem.

Okay , from the simple thought of Extreme programming above we have already get a paradigm of XP collaboration team development .

cheers,

Doddy Ch Saputra,MCPD,MCITP,MCTS

Hi, Geeks …See you again in my blog, in this session I would like to share about the exactly how to define the methodology for our development. I thought that these phase are become the part of a very basic designing the requirement which compulsory to initial our step. The architect and the team need to formulate the methodology based on the type of project, load project and also time line which is supposed to be discussed together with the project manager as a liaison person to the management area.I would like to walk straight ways to some little bit point which are become the main discussion in this session:

1.  I would like to explain and share the main core of each methodology that I’ve known as a practical person.
2. Then we need to perform the team development based on the methodology that we’ve already taken.
3. I would like to share as well about the probability of infrastructure that we need for accommodating your team development, in this case I am refer to use the Team Foundation server and Visual Studio Team Suite edition.

As we known before, there are many methodology for development, for instance we know about waterfall before, and then after water fall really “fall”  due to this methodology following the sequential phase method which couldn’t got adaptation to the fast changing and requirement which driven by deadline and timeline such as this diagram below :

So the conclusion of the legacy failure method of waterfall are :

• Waterfall method failed to deliver the application as intended to the customer in the time frame we predicted because all of the process is sequential but the deadline could move according to the key time line that customer defined, and remember one thing that “…your customer is your king …”
•  Because of the inability in us to deliver the application as the customer want then we felt like don’t have anything to ship to the hold the customer’s confidence.
• Reworking what we have may require ripping out some of what we’ve already built for instance when we are in the midst of project then suddenly there are some accidental requirement come from customer, let say 25 percent from the entire load project , but after we doing re-analyzing again then show 50 even more up to 75 percent of whole entire development supposed to be changed, oops..knock..knock…. your development team will kill you asap due to you will be charged as the most wasting time and energy in the world… J and every developer will hate you pale … 
•   Finally we haven’t driven the risk out of the project because integration is not complete yet  and the time line will always move into the left side. and  then raise new methodology based on the collaboration team with roles activities and involve the customer as the part of whole interaction role, method such as RUP (Rational Unified Process) , Agile Methodology, Agile for CMII  (continuity methodology for Capability mature process)and then for short development is Agile Extreme Programming, in the other side there is a Scum methodology which based on product back log requirement designing, administering by scrum master  and the sprint task as the iteration development methodology.Okay, it’s time to keen our discussion about those method above, first we should to know the essential of each method  :

Currently the  Collaboration team methodology has many elements which refer to agile manifesto (www.agilemanifesto.org), it was a synthesis of common beliefs that underlie the various method whether contain such elements like this :

• Individuals and interactions over process and tools (TDD, Source control and work item traceability)
• Working software over comprehensive documentation (process guidance)
• Customer collaboration over contract negotiation (Timeline management and resources )
• Responding to change over following plan (Iteration process drive the project goal ) 

So, The modern tools of team collaboration development will refer to the Agile Manifesto principle, in next session i will describe one by one of each methodology of SDLC refer to Agile Manifesto.

Cheers,

Doddy Ch Saputra, MCPD,MCITP,MCTS

Hi Developer geeks,

See me again in this session, i would like to share to you about somekind practically method of my experience and expertise during my professional development experiences. Due to many colleagues of mine that was asking me to write down the methodology of software development with the real implementation as a practise , therefore i would like to digest some surrogate keys of enterprise development, first of all that the IT worlds has so huge environment perspectives including the software development that’s why i supposed to aim about the limitation of mine that probably missing the pieces of a factor that i couldn’t  mentioned it in this blogs, but for at least it can contributed some lights that could become a bright way about the Enterprise application development. I devide into some section or session about enterprise development architecturing. in this session i’d like to talk about the initial of development process or in the other word is Pre Development Analysis process. There are many tools that coud drive the collaboration process of team to design the enterprise software, VSTS (Visual Studio Team System) + TFS (Team Foundation Server) are the one of the tools that probably become the best in the market for accomodate this whole of iteration process of enteprise software development, the main reason are this tools could accomodate the skeleton of defining the whole process methodology / ALM / SDLC as an enterprise collaboration team development such as MSF (Microsoft Solution Framework) Agile Methodology, MSF CMII methodology and also SCRUM methodology. Those MSF methodology will drive the all role activies that involved in software development based on their activities and roles which has a final path to QOS (Quality of Service) develoment so it could guarantee the control of the role activies and also the together moving of each role activies into one standard purpose. Okay let’s take a look about the first section picture about how to describe the Pre development analysis of based role activity and functionalities

i will write down each of those details description on that picture above, as you could see above that actually we could devide the pre analysis iteration process into two main section Application requirement design and project timeline and resources, the application requirement design is a zone of technically side of pre development analysis and the project timeline and resources is the grey area and become a bridge of technical world and business world. in teachnicall world zone there are 5 roles involved (SA,BA,Network Engineer,DBA and Developer)  whether coordinate by software architect role and the other zone was hold by the person who could drive the all process into the goal that become the final path of achievement, but i guess from those view point we will have some figures about the pre design of software enterprise development architecture.

see you in my next session,

 cheers,

Doddy Ch Saputra, MCPD,MCITP,MCTS

Hi Folks,

Nice to see you again, in this session i would like to share something nice about practically of high availibility strategies based on my experiences. As we known that all of a IT elements, i mean as a Software architect in application or in Database application had agree about one principle about how to get the goal of application process, especially in data transaction process. The rule is ACID test (Atomicity,Consistency,Isolation and Durability), i wouldn’t talked too much about the detail of these rules due to you can grab the knowledge from many theoritical database book in any where but the things that we should understand is ,between application domain and database should have mutual cooperation to gain this goal in practically, you might take care this rule in transaction process in application by using smart transaction method using ADO.NET or handling smart transaction by using stored procedure in the database. But in in these session, i wouldn’t discuss with you about those things probabaly next session pale , i would like to emphasize the discussion to maintain high availibility in database infrastructure in YUKON or as we known is SQL Server 2005.

Let say i have a scenario mirroring design like this following picture :

Read the rest of this entry »