jump to navigation

Service development process December 4, 2013

Posted by Terry.Cho in ALM (Application Lifecycle Management).
trackback

1. Feature define

This is first step. It gathers user requirement and define features. The feature set can have about 2 depth. Big Feature group and detail feature.

For example if I want to develop “blogging service”

Feature (Lv1)

Feature Lv2

Detail

Post Article

Write text

Write article with text

Attach image

User can upload the image and attach the image in the article

Save as draft

User can temporary store the draft version of posting. The draft version is not posted to other user, only blog owner can see the contents of draft version……

Edit or delete article

After article has been posted, it can be modified later

To write the feature set. Feature should be listed based on user’s service usage flow (sequence)

For example. To use blog service, user has to register the blog service and log in. After log in, user can post article into the blog. The posted article will be displayed in blog. As u can see, It has a sequence.

Feature Lv 1.

Register

Log in

Post Article

Display Article

And the feature description should be enough. It has to be

  • Testable : the description should be enough that test engineer make a test case with the description.
  • UX design : the description should be enough that UX designer can design UX with the description

To define a feature there are some tips.

Competitor analysis

Prototyping

2. UX wireframe (Optional)

After feature define  has been done, it need to draw UX design. It called as “UX wire frame” which is skeleton of UX. For each feature UX flow needs to be defined and each page for the flow should be described. During the UX wireframe design, some missing feature or information can be defined like user profile field etc.


3. Review/rewrite feature and feature lock down

Whey we have to lock down feature?

In Agile methodology, the principal is “requirement is being changed” So in agile, requirement change is always acceptable. And team is defining requirement during the project. Basically I agree and during the project team members are being smarter. But in business world “forecast” is very important. Without feature, marketing team cannot make a plan for advertisement etc. without feature, team cannot estimate cost (for Software/Hardware purchasing). Such a SNS service agile is right. But most of service and product engineering to let other stakeholders plan for them (Marketing plan, recruitment plan, budget plan). Minimum feature should be fixed even if it can be changed later. Even in the big team with out fixed version of feature, making a new feature during the project brings a lot of communication burden.

However, I call this activity as a “Feature Lock down”. After feature has been defined and revised many ways we need to lock down feature.

What is feature lock down?

During the feature lock down phase, we revise the feature with UX wireframe, it will let us to find out missing feature. In addition with restricted resource and timeline, feature will be removed and prioritized to meet a schedule.

Initial version of feature is may be very business oriented term. It is not enough for development. So it need to be changed to more implementation oriented granularity.


4. Architecture design (Conceptual)

After feature lock down has been done, conceptual system architecture should be defined.

Business architecture

The business architecture contains business scenario and restriction etc. It has number of topics like below

1) Service model

Service model describes how the service works and how it makes a business (generate revenue). It should be described in 1~2 page with simple diagram.

  • What major feature is provided ?
  • Who use the feature?
  • How profit is generated?
  • What is external system to interact

2) Business strategy

Business strategy, which contains key value of the service. and strategy like time to market, target user, feature differences compare to other competitor’s service etc.

3) major feature

It describes major feature (level 1. feature) to explain about the service.

4) capacity planning

It has capacity like

  • total number of user
  • concurrent user
  • expected response time
  • TPS (throughput per second)

This capacity planning is very important to estimate system size and budgeting etc.

5) Business road map.

Not just for this phase of project, it also combines big service road map. Feature upgrade plan. or global deployment plan ( ‘14.1Q US, 14’2Q Europe etc)

And also need to define external system interaction like ERP,CRM system in company or 3’rd party solution interaction etc.

Technical architecture

1) Application Architecture

It describes how to the system works in application perspective. To explain it, technical architecture combines 4 things like below.

  • Component : It describes, which component compose the service. The best way to describing component is to user layer approach.

     Like depth 1,2,3, define high level component first and break down. and for the each level, component description should attached.

  • Component relationship : It describes relationship (& dependency) between components. 
  • Component flow per feature : To provide each feature, it explains how component interact together. If Component & Component relationship describes static view. It describes dynamic view per user feature. In the logic flow per feature, component is described and how they interact in time sequence and description of each interaction. 
  • Component interface : It describes interface spec and technology how the components interact each other. It combines interface technology like REST, Protocol buffer, RabbitMQ etc. and interface style (Message Exchange Pattern) Detail interface spec is not combined here. It will be described another document. 

MEP sample diagram from :  https://access.redhat.com/site/documentation/en-US/Fuse_ESB/4.3.1/html/Implementing_Enterprise_Integration_Patterns/files/MsgRout-Multicast.html

After this stage has been done, people can understand what we will make in technical perspective.

2) Solution Architecture

To realize the application architecture, we always need a solutions like web server, web development framework (spring, django etc), rdbms. In solution architecture, technology stack is described. In architecture concept define phase it doesn’t need to be described so detail

3) Technical Architecture (Deployment Architecture)

Technical architecture describes physical hardware or infrastructure architecture like server,disk and network device etc. Or nowdays, in this section Cloud deployment architecture can be described if you will use cloud. In concept phase, detail is not required. But at least what kind of infrastructure is required should be described. (Like Shared file system etc)

4) Data Architecture

data architecture describes, how data is stored, and where the data will be stored. In concept phase, domain modeling is very important. What kind of entity is involved. What is relationship between the entities. Even if i described full frame of Architecture design concept, it doesn’t need to be such detail. It is enough to explain big concept of architecture.

5. Technology selection & prototyping (Optional)

After big architecture has been defined, it needs to select solution. Now days software development is not “build from scratch” but “stitching solutions and software”. So selecting appropriate solution is very important. Actually this is not mandatory, but I highly recommend to have technology selection phase before start development. There are number of decision items to choosing the technology

  • Popular : Popular technology has a lot of information in web. (it means it can get a help or information from logs of blog etc).There are number of tips to measure technology popularity. Google trends (http://www.google.com/trends) shows interest of such keyword. For example if u want to compare two different solutions like mongodb vs couchdb. Google trends shows comparison of the search keyword. By using that u can recognize which solution is more popular
    another way is using “job search site”. If u find job position with technology keyword. You can find out which technology is more popular. By using same way u can get a same information from Amazon Book. “Stackoverflow.com” is also very good site to know the technology trend.
  • Supportable: Solution sometimes needs a support like a training, consulting sometimes maintenance like bug fix, enhancement etc. In case of commercial solution, it can be supported usally. But if there is no subsidiary in your country or don’t have skilled counsultant or engineer in you country, it is hard to get support. Open source case, subscription or commercial supported vendor is very useful in initial phase. If there is no commercial supported open source, the open source community should be strong to get a support from the community.
  • Easy to learn : Learning curve is very important
  • Cost
  • Reference
  • Market share
  • Meet in requirement

After you filter number of candidate technology, there is a way to measure the technology

  • PoC
  • BMT
  • Prototyping

6. Planning

Resource Planning

Budget Planning

7. Detail Architecture Planning

8. Interface design (On going)

9. Development environment set up

10. Development with Scrum (Iterative)

11. Retrospective and enhance. (Iterative)

12. QA

13. Production Release

14. Operation

 

Role & Responsibility

Advertisements

Comments»

No comments yet — be the first.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: