'Development'에 해당되는 글 7건

  1. 2010.01.13 [Dev] Software developement process...
  2. 2009.12.04 [Dev] Sharing between members and leader...
  3. 2009.08.01 [Dev] Key point to succeed in large project...
  4. 2008.10.23 [Dev] User Interface Specification in Handset Software Development
  5. 2008.10.17 [Dev] Time oriented vs Quality oriented development
  6. 2008.09.22 [Dev] Items to check in the first step for co-working.
  7. 2008.09.20 [Development] Why should we shorten product developement time?

[Dev] Software developement process...

Development 2010.01.13 22:07
[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

 My personal definition of software development process. (There aren't any grounds for this except for my experience.)

1. Rough analysis
  - Analyzing requirements.
  - Analyzing features and functionality that are required.
  - Analyzing required schedule.

2. Detail analysis
  - Defining the way to measure project's completeness.(When can we say "We complete this project!")
  - Defining risks.
  - Estimating costs and time.
  - Deciding whether to go or not.

3. Planing
  - Making reasonable schedule.
  - Confirming resource plan.
  - Confirming the way to measure project's progress - including Milestone. (ex. if XXX is YYY, then project is oo% completed.)
  - Planning schedule, solution and alternatives etc about risk management.

4. Development
  - Determining development environment. (ex. language, CM tool, etc.)
  - Designing SW.
  - Making test plan and cases.
  - Implementation & debugging.

5. Maintenance

신고
tags : development
Trackback 0 : Comment 0

[Dev] Sharing between members and leader...

Development 2009.12.04 22:16

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

The team member (henceforth member) needs to report current state (what he/she is doing and progress etc) frequently to team leader (henceforth leader); Leader always want to know what members are doing.
On the contrary, leader needs to tell members what he/she wants to be done.

Usually, leader set the vision, goal and direction; members make those come true. Members cannot decide what they should do if they don't have any idea about what leader wants.; It is same to the leader. Leader cannot make right decision about the future goal and vision without knowledge of current state of what members are doing.

So, "Sharing current state and goal" is very important to team.

In general, members know about practical state and issues better than leader. And leader understands external situation better and studies vision and future goal harder than members.

Now, it's time to share it!!

(Is it too trivial to discuss? Never!.)

신고
tags : development
Trackback 0 : Comment 0

[Dev] Key point to succeed in large project...

Development 2009.08.01 22:15

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

There lots of books and guides about project management. But in my opinion, most important and efficient way is "Divide and Conquer". In general, small-size-project is easy to succeed regardless of methodology. So, most important thing to succeed is "Dividing large project into several small independent projects". We should focus and spend time on this!!!

( Yes.. I know..."Easier said than done!" :-( )

신고
tags : development
Trackback 0 : Comment 0

[Dev] User Interface Specification in Handset Software Development

Development 2008.10.23 14:06

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

Requirement is one of most popular cause of problem in software development. Change of requirement always affect overall software development, severely. I want to skip general things about Requirement because there are already lots of stuffs about this. Let's just focus on Requirement of Handset software development. Especially, User Interface Specification (henceforth UIS).

In general, there is department in charge of UIS. The department composes UIS. Then, this UIS is delivered to Development team (development team design software big picture based on this.), designers(designers make images, screen layouts etc based on this), and test team (test team makes test and verification cases based on this.)
As you see, the point is "UIS's impact in the software development is extremely critical.". And usually, number of people who make UIS not alone. And it is true for design, software development and test. Let's image that UIS is not clear. What will happen? In this case - development based on unclear UIS -, huge amount of communication overhead is required between UIS, design, development and test team. This cost is extremely large - over than expected. (I can say like this based on my experience. Believe me.)

Even though clarity of UIS - we can also say it as 'completeness' - is very important, in many cases, it is underestimated. Instead of clarity, originality or creativity of UIS is usually required. I'm not saying that originality and creativity are not important. My point is, clarity or completeness is as important as originality or creativity.

UIS is also a kind of "Specification". So, it should be clear. That's my point.

신고
tags : development, UIS
Trackback 0 : Comment 0

[Dev] Time oriented vs Quality oriented development

Development 2008.10.17 00:36
[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

It is already well known and proved that quality oriented development is better than time oriented development in terms of quality and time.

Time Oriented Development
Developing software with fixed schedule. For example, we should complete this project by 10th of March.
In this case, usually, functionality has priority to show progress. And, quality is put behind. So, software is not tested enough during development. Usually, real stage for test and debugging begins at the latter part of project. This is main cause that make time for test and debugging be longer than expected.

Quality Oriented Development
Development focusing on software quality. Software continuously tested during development to keep software quality good. So, software is debugged at the early stage. So, cost for debugging lessen(It's well known that debugging at the early stage is much cheaper than debugging at the latter stage.). This shorten time and increase quality.

신고
tags : development
Trackback 0 : Comment 0

[Dev] Items to check in the first step for co-working.

Development 2008.09.22 22:10
[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

1. Sharing team roaster and contact point.
(members need to know mapping between person and job.)

2. Sharing development environment. (if possible, harmonize environments.)
(Using same development environment can reduce communication overhead dramatically.)

신고
tags : development
Trackback 0 : Comment 0

[Development] Why should we shorten product developement time?

Development 2008.09.20 21:43

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

[Note: I'm not talking about costs. We can develop something with very low cost for long time.(ex. 1 person for 5 years..)]

Predicting the future is always very difficult. The further is more difficult!
We should predict market situation(the future) when product is released. So, development time means future we should predict. "1-year-development" means "We should predict 1-year-later-future". But, "3-month-development" means just "predicting 3-month-later-future".

Can you understand how important this is?!!!

신고
tags : development
Trackback 0 : Comment 0