Doddy Christiana Saputra

With Activity Diagram ,If anyone has used flow charts, they know almost all details of activity chart. The following image shows all the elements which can be used to create activity diagram. Although both Use Case and Activity diagram can model the requirements, while Use Case provides the scope in the nutshell, activity diagram provides the flow of activities in a serial and specific order. It shows the business processes which are executing.

(more…)

Till VSTS 2008 there was no support for various architectural diagrams which form the UML. Team Edition for Software Architects supported some non-UML but very practical diagrams. Those diagrams provided us ability to do High Level Design of solution architecture and infrastructure architecture. Except in case of WebService the Application Diagram did not support the Low Level Design and on the infrastructure side, except for deployment diagram no other design elements were supported. Team System 2010 for Architects has quite a number of enhanced capabilities compared to Team Edition of Software Architects 2008. Distributed Diagrams model which was present in the Team Edition for Software Architects 2008 is no longer available with Team System 2010 for Architects.
First two phases of traditional Microsoft Solution Framework (MSF) are Envisioning and Planning. Although some of the architectural diagrams are started to be created in envisioning, the completion of those happen during the planning phase. Planning phase is further divided in three processes which run to an extent parallel but are started with a little bit of phase difference. Those processes are:

· Conceptual Design
· Logical Design
· Physical Design

In this article we will look at the details of various diagrams which are required during each of the design process and check if it is supported by Team System 2010 for Architects. Architectural diagrams can be created using Team System 2010 for Architect in which there is a project template for ‘Modeling Project’ which allows us to create various diagrams. We will take an overview of those in the article.
Conceptual Design: This is a process in which from a hazy cloud of needs, crystallization of requirements happens. Requirements are gathered, analyzed and prioritized. Requirements are modeled using ‘Requirement Document’ and ‘Use Case’ diagrams. We also document the processes that are followed by the business. These processes are workflows within the business system. We can use ‘Activity Diagram’ to model those processes and workflows. During the conceptual design the architect will also list all the user roles that will be interacting with the system and the general architecture of the system. General architecture definition will contain the list of logical layers and physical tiers which will be present in the future state of the system. To model it, we can use the ‘Layer diagram’ which is available in the Team System 2010 for Architects.

(more…)

Microsoft’s upcoming Visual Studio Team System 2010 release is anchored in efficiency and code quality, incorporating new ALM, architecture and testing tools. As the release draws nearer, the company is continuing to flesh out those features, and developers are learning how to adapt their workflows to its new capabilities.

(more…)

Hi dude,

Much of topics that i was discussed  in my previous post about TFS collaboration in Axapta, herewith the resume of it to make a recipe for us to implement it :

(more…)

Hi Developers,

Version control is the core of agile collaboration development for these days, why ? because when we talked about collaboration development project, our first head is we involve so many developers and it’s element with in, and we need the mechanism to manage that, not possible closed to development in ERP Microsoft Dynamics Axapta 2009 the daily development happen and often is develop the AOT ( Application Object Tree ) structure and architecture ,because this is the layer of what we called the ERP Customization in Axapta, so let’s take a look this picture below :

(more…)

Well,

Praise the lord for the moment that i have shared my expertise to my fellow developer in Indonesia at Microsoft Event which called by MSDN DAY on october 28,2008, This MSDN day talking about the Topic of Life cycle Management process by using Visual Studio Team System and Team Foundation Server 2008, i take a part of bring the Architect Software perspective and i put the QoS Mindset design and System Definition Model of Distributed architecture design and each element which catered by VSTS 2008. Here are some following moment and agenda :

cheers,

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

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