'Excerpt'에 해당되는 글 16건

  1. 2010.01.10 [Prog][Excerpt] Extensive computer use is correlated with low productivity.
  2. 2009.06.21 [Prog][Excerpt] Top-down vs Bottom-up design
  3. 2009.05.18 [Prog][Excerpt] Only 10% is written for nominal cases.
  4. 2008.07.19 [Dev][Excerpt] 죠엘 test의 항목들.
  5. 2008.05.22 [Dev][Excerpt] Using interpreted language...
  6. 2007.04.22 [Prog][Excerpt] Ratio of High-Level-Language Statements to Equivalent Assembly Code
  7. 2007.03.12 [Dev][Excerpt] Typical Architectural Components
  8. 2007.03.09 [Dev][Excerpt] Software Schedule/Effort Equations.
  9. 2007.03.09 [Dev][Excerpt] Shortest Possible Schedules.
  10. 2007.03.05 [Dev][Excerpt] Requirement change ratio

[Prog][Excerpt] Extensive computer use is correlated with low productivity.

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

A study at the Software Engineering Laboratory - a cooperative project of NASA, Computer Sciences Corporation, and the University of Maryland - found that extensive computer use (edit, compile, link, test) is correlated with low productivity. Programmers who spent less time at their computers actually finished their projects faster. The implication is that heavy computer users didn't spend enough time on planning and design before coding and testing (Card, McGarry, and Page 1987; Card 1987).
신고
tags : Programming
Trackback 0 : Comment 0

[Prog][Excerpt] Top-down vs Bottom-up design

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

[Extracting from Wikipedia]

Software development

Part of this section is from the Perl Design Patterns Book.

In the software development process, the top-down and bottom-up approaches play a key role.

Top-down approaches emphasize planning and a complete understanding of the system. It is inherent that no coding can begin until a sufficient level of detail has been reached in the design of at least some part of the system. The Top-Down Approach is done by attaching the stubs in place of the module. This, however, delays testing of the ultimate functional units of a system until significant design is complete. Bottom-up emphasizes coding and early testing, which can begin as soon as the first module has been specified. This approach, however, runs the risk that modules may be coded without having a clear idea of how they link to other parts of the system, and that such linking may not be as easy as first thought. Re-usability of code is one of the main benefits of the bottom-up approach.[citation needed]

Top-down design was promoted in the 1970s by IBM researcher Harlan Mills and Niklaus Wirth. Mills developed structured programming concepts for practical use and tested them in a 1969 project to automate the New York Times morgue index. The engineering and management success of this project led to the spread of the top-down approach through IBM and the rest of the computer industry. Among other achievements, Niklaus Wirth, the developer of Pascal programming language, wrote the influential paper Program Development by Stepwise Refinement. Since Niklaus Wirth went on to develop languages such as Modula and Oberon (where one could define a module before knowing about the entire program specification), one can infer that top down programming was not strictly what he promoted. Top-down methods were favored in software engineering until the late 1980s, and object-oriented programming assisted in demonstrating the idea that both aspects of top-down and bottom-up programming could be utilized.

Modern software design approaches usually combine both top-down and bottom-up approaches. Although an understanding of the complete system is usually considered necessary for good design, leading theoretically to a top-down approach, most software projects attempt to make use of existing code to some degree. Pre-existing modules give designs a bottom-up flavour. Some design approaches also use an approach where a partially-functional system is designed and coded to completion, and this system is then expanded to fulfill all the requirements for the project

Programming

Top-down is a programming style, the mainstay of traditional procedural languages, in which design begins by specifying complex pieces and then dividing them into successively smaller pieces. Eventually, the components are specific enough to be coded and the program is written. This is the exact opposite of the bottom-up programming approach which is common in object-oriented languages such as C++ or Java.

The technique for writing a program using top-down methods is to write a main procedure that names all the major functions it will need. Later, the programming team looks at the requirements of each of those functions and the process is repeated. These compartmentalized sub-routines eventually will perform actions so simple they can be easily and concisely coded. When all the various sub-routines have been coded the program is done.

By defining how the application comes together at a high level, lower level work can be self-contained. By defining how the lower level abstractions are expected to integrate into higher level ones, interfaces become clearly defined.

Top-down approach

Practicing top-down programming has several advantages:

* Separating the low level work from the higher level abstractions leads to a modular design.
* Modular design means development can be self contained.
* Having "skeleton" code illustrates clearly how low level modules integrate.
* Fewer operations errors (to reduce errors, because each module has to be processed separately, so programmers get large amount of time for processing).
* Much less time consuming (each programmer is only involved in a part of the big project).
* Very optimized way of processing (each programmer has to apply their own knowledge and experience to their parts (modules), so the project will become an optimized one).
* Easy to maintain (if an error occurs in the output, it is easy to identify the errors generated from which module of the entire program).

Bottom-up approach

Pro/ENGINEER WF4.0 proetools.com - Lego Racer Pro/ENGINEER Parts is a good example of bottom-up design because the parts are first created and then assembled without regard to how the parts will work in the assembly.

In a bottom-up approach the individual base elements of the system are first specified in great detail. These elements are then linked together to form larger subsystems, which then in turn are linked, sometimes in many levels, until a complete top-level system is formed. This strategy often resembles a "seed" model, whereby the beginnings are small, but eventually grow in complexity and completeness.

Object-oriented programming (OOP) is a programming paradigm that uses "objects" to design applications and computer programs.

In Mechanical Engineering with software programs such as Pro/ENGINEER, Solidworks, and Autodesk Inventor users can design products as pieces not part of the whole and later add those pieces together to form assemblies like building LEGO. Engineers call this piece part design.

This bottom-up approach has one weakness. We need to use a lot of intuition to decide the functionality that is to be provided by the module. If a system is to be built from existing system, this approach is more suitable as it starts from some existing modules.

Pro/ENGINEER (as well as other commercial Computer Aided Design (CAD) programs) does however hold the possibility to do Top-Down design by the use of so-called skeletons. They are generic structures that hold information on the overall layout of the product. Parts can inherit interfaces and parameters from this generic structure. Like parts, skeletons can be put into a hierarchy. Thus, it is possible to build the over all layout of a product before the parts are designed.

신고
Trackback 0 : Comment 0

[Prog][Excerpt] Only 10% is written for nominal cases.

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

90 percent
 of a program's code is written for exceptional, error-processing cases or housekeeping, implying that only 10 percent is written for nominal cases (Shaw in Bentley 1982).
신고
Trackback 0 : Comment 0

[Dev][Excerpt] 죠엘 test의 항목들.

Excerpt 2008.07.19 22:12

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

아래의 항목은 "죠엘"의 블로그에 소개되어이 있는 내요들이다. 뭐 100% 동의하는 것은 아니지만, 충분히 기억해 둘 만하다.

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

신고
tags : development
Trackback 0 : Comment 0

[Dev][Excerpt] Using interpreted language...

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

Developers working in interpreted languages tend to be more productive than those working in compiled language (Jones 1986a).
신고
tags : development
Trackback 0 : Comment 0

[Prog][Excerpt] Ratio of High-Level-Language Statements to Equivalent Assembly Code

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

Language                     Ratio

-----------------------------------------------------------
Assembler                    1 to 1
Ada                          1 to 4.5
Quick/Turbo Basic            1 to 5
C                            1 to 2.5
Fortran                      1 to 3
Pascal                       1 to 3.5

< Source : Applied Software Measurement (Jones 1991) >

신고
Trackback 0 : Comment 0

[Dev][Excerpt] Typical Architectural Components

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

From ( "Code Complete", McConnell )
  - Program organization
  - Change strategy
  - Buy-vs.-build decisions
  - Major data structures
  - Key algorithms
  - Major objects
  - Generic functionality
  - User interface.
  - input/output
  - Memory management
  - String storage (optional)
  - Error processing
  - Over-enginerring
  - Assertions
  - Fault tolerance
  - Performance
신고
tags : development
Trackback 0 : Comment 0

[Dev][Excerpt] Software Schedule/Effort Equations.

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

▶ Software Schedule Equation.

Schedule in months = 3.0 * power (man-month, 1/3).

65 man-months job : 30 * power(65, 1/3) := 12.
So, in this case, "team with 5~6 members works for 12 months" is ideal.

 
▶ Schedule Compression Factor.
schedule compression factor = desired schedule / initial schedule.

[initial schedule 12 months.]
To advance this to 10 months : compression factor = 0.83 (10 / 12)

 
▶ Compressed Schedule Effort.
compressed schedule effort = initial effort / schedule compression factor.

[initial schedule is 12 months, initial effort is 78 man-months.]
To advance this to 10 month :
compression factor = 0.83 (10 / 12)
compressed schedule effort = 94 man-months (78 / 0.83)
=> To advance schedule by 17%, 21% more effort is required.

 
NOTE :
  It is impossible to make schedule compression factor be below 0.75 or 0.80.
  (Bohem 1981; Putnam and Myers 1992; Jones 1994)
=> This means, no matter how much effort is available, we cannot advance schedule by more than 25%.; In this case, we should cut back on product size itself.

< From "Rapid Development" (Steve McConnell) >

신고
tags : development
Trackback 0 : Comment 0

[Dev][Excerpt] Shortest Possible Schedules.

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

 Systems ProductsBusiness ProductsShrink-Wrap Products
System Size
(lines of code)
Schedule
(month)
Effort
(man-month)
Schedule
(month)
Effort
(man-month)
Schedule
(month)
Effort
(man-month)
10,0006 25 3.5 5 4.2 8
30,0009 110 5.5 22 7 37
50,00011 230 7 46 8 79
100,00015 540 9 110 11 190
200,00020 1,250 11 250 14 440
300,00024 2,100 14 420 16 725
500,00030 3,900 17 780 20 1400

< Sources : Derived from data in
Software Engineering Economics (Boehm 1981),
"An Empirical Validation of Software Cost Estimation Models" (Kemerer 1987),
Applied Software Measurement (Jones 1991),
Measures for Excellence (Putnam and Myers 1992),
Assessment and Control of Software Risks (Jones 1994)>

신고
tags : development
Trackback 0 : Comment 0

[Dev][Excerpt] Requirement change ratio

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

A study at IBM found that the average project experiences a 25 percent change in requirements during development (Boehm 1981).
신고
tags : development
Trackback 0 : Comment 0