Doddy Christiana Saputra

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 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

Interviewers: Scott Swigart and Sean Campbell.

Interviewees:Blaine Wastell and Glenn Block.

In this interview with Blaine Wastell and Glenn Block of the Patterns and Practices Group at Microsoft we asked them about:

• About the Patterns and Practices Group
• What makes them different from a typical product development group
• The software development methodology they use
• Some of the things that Patterns and Practices group has produced for developers.
• The role of CodePlex for their group.

Blaine:   I’m Blaine Wastell. I’m a program manager in patterns & practices, and I’ve been in this role for a little over four years now. Most recently my focus has been in what we call the “client UX program”. It’s about providing guidance to customers on developing both smart client and web client applications.

For 12 years before Microsoft I was out in the consulting world helping business customers develop enterprise line of business applications, mainly Web applications.

(more…)