Ting 이네 Software 이야기

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

[[ 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!.)

[[ 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!" :-( )

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

Before developing something, we should clarify "what we want to develop". In the same context, we want clear requirement specification. But I am not saying about requirement specification. Subject of this article is "Clear description about outcome - not only final one but also intermediate and sub-module's one". In case of very short and simple program, required goal is also simple and clear. So we don't need to worry about this. But, usually, size of software project is quite big.

Here is very big-size-software project. So, we divide a project into several sub-projects and assign these to sub-team; After developing each sub-project, we try to integrate them. But, as you know, integration is not an easy job. There may be conflicts between sub-module, interface mismatching and so on. Changing software design or algorithm may be required to resolve these integration issues, and usually, this kind of change is very expensive. How can we reduce this costs?.

Yes. I think everyone already knows the solution.To reduce this, we should clarify outcome of each sub-project.
Actually, changing software due to integration issues means "Requirement of that sub-project is changed"; Big Costs!. In this scenario, outcome of sub-project can be interface, data format and so on. In sub-teams' point of view, "Knowing exactly about outcome of other module" means "Knowing exactly what we can use and what we can supports". In my opinion, this is basic knowledge to reduce integration issues.

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

Let's consider a software project.

Usually, we have two general way to make up team.
1st : We may organize one team for each project. That is, one team for one project. And this team - actually, team lead if we should pick only one person - is fully responsible for the project.
2nd : one team for each features.(for example, WAP team, MMS team etc...)

We cannot tell which model is better (each model has it's own pros and cons.).
But, in terms of time-critical project, 1st model is better.
In the 1st model, issues detected during project development are definitly under project team's responsibility. So, we don't need to struggle for finding appropriate team to handle those issues. And this project team tends to be active to resolve those. (But, Several teams may suffer same issues with high possibility, because sharing know-how and accumulating knowleges about each feature is difficult)

But, in 2nd model, it is difficult and takes time to know which team should handle those - for this, usually lots of communication overhead is required. So, each feature team tends to be passive. And they want to avoid being assiged to issues, because they don't have responsibility to succeed this project. (But, in this case, each feature team can accumulate know-how about features and expect synergy from this because team becomes expert for the feature!)

We should take attention to main difference between 1st model and 2nd model. That is just "Is there any ONE person who are fully responsible for the project?".

So, we would better to mix up this two models. (ex. 1st model for SW maintenance and enhancement; 2nd one for making product.)

My point to succeed in time-critical-project (ex. making product), (based on my experience..) is,

* There should be only ONE person who are fully responsible for a project and he/she should have enough authority to manage this project. Responsibility of several people means "No one under responsibility".

Does it seems too simple and trivial? But, it is not easy to obey this rule efficiently.

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

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.

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

[[ 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?!!!

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]
 
아래의 항목은 "죠엘"의 블로그에 소개되어이 있는 내요들이다. 뭐 100% 동의하는 것은 아니지만, 충분히 기억해 둘 만하다.

1. 소스코드 관리시스템을 사용하고 있는가?
2. 한 번에 빌드 결과물을 만들어낼 수 있는 script를 사용하고 있는가?
3. 일일 빌드를 하고 있는가?
4. 버그 추적시스템을 운영하고 있는가?
5. 코드를 새로 작성하기 전, 매 baseline마다 알려진 모든 버그를 수정하는가?
6. 일정을 업데이트 하는가?
7. 요구명세서, 설계명세서 등 명세서를 작성하는가?
8. 개발자에게 조용하고 개인적인 작업환경을 제공하는가?
9. 경제적인 범위 내에서 최고의 성능의 도구를 사용하는가?
10. 테스터를 별도로 두고 있는가?
11. 프로그래머 채용 인터뷰 때 코딩 테스트를 하는가?
12. 무작위 사용편의성 테스트를 수행하는가?