Планирование проекта

[Kinsler]

народ, а вы используете какое-то графическое представление будущего проекта?
Я имею в виду логику и т.д.
Сам вид это что-то наподобие схем (к примеру в visio)
просто тут писал некую штуку со сложной логикой
под конец работы пришла мысль оформить все в виде схемы, чтобы самому проще было, ибо путался :(
еще читал про такие помогающие программы в каком-то номере компьютерры, к сожалению не помню в каком и автора, но что-то про дата-майнинг, может быть кто-то вспомнит?
Мне там одна програмка понравилась в четкости представления ...

[artcraft]

Меня этот вопрос тоже очень интересует.

можно пользоваться UML (http://ru.wikipedia.org/wiki/UML)
есть такая программа - Enterprise Architect (http://www.sparxsystems.com.au/), она поддерживает импорт готового as2 / as3 кода в UML и экспорт обратно.
Я пару раз пробовал к ней подступиться, но так и не освоился - удобнее на бумажке чирикать гелевой ручкой.

но почеркухи на моих мятых бумажках трудно назвать "архитектурой", поэтому я буду рад узнать побольше о методах планирования

[etc]

Бумажка :D

[Kinsler]

2 artcraft
завтра посмотрю
2 __etc ну блин бумажка бумажкой, но ведь 21 век на дворе :)
я положим дизайн сайта тоже карандашом сначала рисую, но это несколько другое таки ...

[etc]

А мне так проще :)

[udaaff]

Лекции по UML (http://www.intuit.ru/department/pl/umlbasics/)

имхо лучше использовать листик с ручкой, что я и делаю. :)

[Nirth]

ЮМЛ это эм..гм ну я поюзал мне не понравилось.

На маках есть OmniGraffle удобная штука для создания схем, аналог на виндах Microsoft Visio но вижио больше, и тяжее в освоении.

А вообще сначала все на Whiteboard/бумаге.

[Nirth]

Кстати __etc ты спрашивал меня о софте для маков

зайди на omnigroup.com.
Маст хэв - OmniOutliner, OmniGraffle.
Идеальные вещи для записи и организации идей(первый в текстовом виде, второй в графическом).

[Molecula]

Юзал Визио и ЮМЛ - не очень понравилось,..бумажка ближе к сердцу, но ещё ближе...смеяться будете, но Corel :)
Как ни странно, мне в нем очень удобно делать схемы для небольшого проекта, сделать наброски плана и т.д., в основном структуру (т.е. мы пока не говорим о мат. вычеслениях) для того что бы посмотреть на проект чуть сверху.
Курсовую сдавал в Универе, там в ЮМЛ нужно было показать схемы, нифига не могу понять, как там чертить, в Кореле нарисовал, никто даже не заподозрил, что это подделка.

[Ekzi]

бумага рулит=) не противные a4 ,а а3 или а2 простите за каламбур

[udaaff]

to E.x.E.
меня и A5 устраивает :)

[etc]

Nirth, спасибо, посмотрю.

[flastar]

Люди, какие УМИ, какие ********************** ?
Зачем???
Бумага, наш выбор!!! Нарисовал, стёр, нарисовал, подправил, дорисовал готово.)))))))) ----------> Моё мнение.
Делайте так как вам удобно.

[CrazyFlasher]

бумажка и ручка незаменимы =)

[Kinsler]

да блин :)
21 век
народ пишет на AS3 а план рисует на бумажке :)
прогресс....

2 Nirth ну положим у меня Visio все равно освоен достаточно давно ....
надо попробовать таки в нем

а то я на прошлый проект столько времени тратил на обдумывание связей и логики, что опоздал со сдачей на три дня :)

[KidsKilla]

пипол, юмл сделан для больших проектов с командой. там где разбираться в проекте нужно не 1му челу а 2, 5, 100...

[aksios]

У буржуинов есть масса литературы про планирование веб разработок. Там все расписано. Везде сказано, что карандашом на бумажке или бланке надо пачкать однозначно. Софтяра типа прожекта и хелп десков в основном для групового с.... т.е. разработки.

[iNils]

Доска и маркер.

[artcraft]

меня как раз интересует планирование больших проектов для организации удалённой групповой работы...
поэтому бумага и доски с фломастерами тут не совсем подходят...

[artcraft]

а можно посмотреть на ваши бумажки? как вы там себе всё рисуете?

[Fr@ddy]

ну когда удаленная групповая работа, то конечно бумажки не пойдут, разве что по почте их в конвертиках не пересылать :D а когда один, то блокнотик/бумажки очень даже удобны.

[artcraft]

вот мои наброски

http://i13.tinypic.com/4q4nrih.jpg

[flastar]

оооооо что эт ты набрасывал?

[7thsky™]

iNils дело говорит - доска и маркер :) большая доска вмещает почти весь проект, со всеми связями спороми и так далее, не понравилось стер и перерисовал

[artcraft]

это крупный проект, который в идеале нужно разделить на человек 5-7, но оформление документации не достаточно ммм... доступное... поэтому приходится всё делать самому :~/

[artcraft]

хорошо, доска или бумага.
что вы там рисуете, и как? как например вы изображаете наследование, взаимосвязи, события, публичные свойства и методы? как?
покажите.

[iNils]

http://www.gskinner.com/gmodeler/

[Ромастый]

Если требуется (для себя) получше утрясти решение задачи в голове перед реализацией - то бумага+карандаш.
Если же визуальная "подсказка" должна храниться довольно долго, чтоб можно было освежить в голове -то в visio. Причем не обязательно в UML, порой хватает примитивных блок-схем.

[artcraft]

http://www.gskinner.com/gmodeler/
видел, поленился искать ссылку...
снова UML, его только что тут все дружно облажали как уступающий бумаге по удобству

[iNils]

Я не считаю, что UML хуже бумаги, скорее инструментарий не всех устраивает, либо слишком сложный, либо слишком убогий. А на бумаге нельзя сдублировать, перетащить, перегруппировать. Да и выглядит порой нечитабельно.

[Kinsler]

Нилс прикольная штучка
что-то наподобие я и имел в виду
Написать чтоли под себя такую же :)

[Dimchansky]

оно, конечно, дело вкуса, но после освоения GoF, Фаулера, Кириевски - UML для дизайна + доска и маркер для комманды + бумага и карандаш для себя.

[artcraft]

можно подробнее про GoF, Фаулера и Кириевски?

[Tardos Mors]

А GoF переведен на русский?
Очень хочется почитать.

[Mr. Fixit]

Реально бумага рулит..
а то устают глаза создавать проект полностью перед монитором.

[Molecula]

Нужно бумагу придумать - что бы на ней клонировалось, перетаскивалось, ну и так далее...

[artcraft]

фрагмент из книжки Advanced ActionScript 3 with Design Patterns.
кто переведёт?


Chapter 1. Designing Applications

One of the most frequent questions ActionScript developers ask is, "How do I know what constitutes a class?" This question strikes at the heart of a larger dilemma, which is: What are the steps for building a successful application from start to finishfrom concept to completion? This is a big topic to tackle. Many people dedicate themselves to understanding and improving methodologies to answer this question.

The difficulty with teaching someone how to design and build an application from start to finish is that it requires elements that are difficult to talk about much less teach. It requires being able and willing to look at the big picture as well as looking at things from many perspectives. It requires creative thinking as well as abstraction. It requires practice and experience. But there are steps you can follow to help with the learning process. There are technologies you can use to assist you in developing your ActionScript classes. This chapter outlines some of the steps and technologies that have proven useful for many ActionScript developers.

Some methodologies say there are five steps for building applications; other methodologies say there are eight steps; still others can't decide how many steps it takes. In general, most developers agree that there are at least three phases to building successful applications:

1. Analysis

2. Design

3. Implementation

In addition, most developers also agree that testing is a vital part of the application development process. Although not always considered a core phase we'll also look at testing as a fourth important phase.

As we look at each of these phases, remember that they are not necessarily linear. You can go back to an earlier step at any point if necessary. During the design phase, for example, you might realize that you forgot about an important use case for your application. At that point, you can return to the analysis phase. However, you should be as thorough as possible at each step. Don't jump to the design phase too early just because you can. The more thorough and complete you are with each phase before moving to the next, the more successful your application is likely to be. Additionally, thoroughness at each phase helps minimize the risk that you'll have to make major architectural changes later on, which could severely impact schedules and project success.


The Analysis Phase
The analysis phase is concerned exclusively with what the application is supposed to do. The question of how the application will accomplish the goal is deferred to the design and implementation phases. In many ways, the analysis phase can be the most challenging because it requires that you take (often vague) ideas and translate them into specific functional requirements. You must create a map of what the application looks like from a distance. Although you can get away with a minimal analysis phase for a small project, the analysis phase becomes increasingly important for a project's success as the project increases in size and scope. Although you might be able to walk around your neighborhood without a map, if you wanted to cross the country, you'll undoubtedly agree that you need a map. This is true of application development as well.

All too often, the analysis phase is glanced over or deemphasized. Poor analysis leads to frustration for all parties involved (the developers who have to constantly make guesses and refector, the managers who have the responsibility to see the project through to a successful completion, the client who wants the working application, customers that have to use the application that may suffer from limited feature sets and bugs due to poor analysis, etc.). The goal of analysis is to provide a clear specification that outlines the needs of the user. Unlike later phases, the analysis phase should be as non-technical as possible.

The outcome of the analysis phase is generally a document that outlines the functional requirements. However, it's important to understand that there are many ways to approach gathering these requirements, and the resultant document has no one required format. What is most important is that you, your team, and/or your company uses an approach and document format that works best for you while still achieving the goal of clearly defining this map for the application you want to build.

Although there's no one required approach or format, we'll present one common approach to analysis using use cases. If you are new to the idea of doing formalized analysis then you may find it useful to try using use cases. We also encourage you to research other techniques and document formats to find what works best for you.

Introducing Use Cases
One way to define the functional requirements of an application is simply to list everything that the application should be able to do. Although that approach is not necessarily wrong, it is naïve in that it fails to take into account the real-world use of the application. Applications don't exist in isolation; they interface with all sorts of users. Therefore, it's much more realistic and useful to approach the functional requirements from the standpoint of how the application is used. This approach naturally leads to a kind of functional requirement called use cases.

Use cases present the application requirements by showing various ways in which users might interact with the application. The following is an example of a simple use case:

- Generate Map: The user submits a form with a street address. The system displays a physical map of the street address, with the map zoomed in at the default level.

Use cases can be formatted in many ways. Generally, use case experts talk about three basic formats.

Brief: One paragraph outlining the main success scenario. The preceding example was in the brief format.

Casual: Multiple paragraphs outlining not only the main success scenario, but also alternative scenarios. The following is an example of a casual format use case:

- Generate Map

Main success scenario: The user submits a form with a street address. The system displays a physical map of the street address, with the map zoomed in at the default level.

Alternative scenarios: If the address is invalid, the address form is redisplayed with an error message notifying the user why the operation failed.

If the default zoom level is unavailable for the requested address, display a map at the greatest zoom level available for the location.

Formal: The most elaborate of the formats for a use case document. This format lists all the steps for the use case as well as supporting data such as actors and conditions. The formal use case is discussed in more detail in the next section.

Writing Formal Use Cases
Typically you'll want to create formal use cases for a functional requirements document. In this section we'll look at how to create a formal use case. A formal use case can include the following sections:

- Primary actor: A description of the user who drives the operations outlined by the use case. The description of the primary actor can include things such as the role of the user (e.g. anonymous, basic, administrator, etc.) as well as characteristics of the user that may be relevant to how they interact with the application (e.g. age, disabilities, etc.)

- Preconditions: Those conditions that must be met for the use case to proceed.

- Main success scenario: A more granular, step-based description of the way the application works than is given in the basic or casual formats.

- Alternative scenarios: More granular, step-based descriptions of the ways the application will handle alternative uses than are given in the casual format.

- Special requirements: A list of requirements for the use case that don't fit as part of the main or alternative scenarios.

- Open issues: A list of notes including questions that must be answered to fully implement a solution for the use case.

The following is an example of a formal use case. Note that this example does not have any open issues.

- Generate Map

Primary actor: Customer

Preconditions: Customer is already viewing the form that allows the user to specify an address and click a button to submit the form.

- Main success scenario:
1. Customer fills out address form.
2. Customer submits address data.
3. System requests map data from mapping service.
4. System draws map at default zoom level.

- Alternative Scenarios:

3a. System detects invalid address format and redisplays form with error message.
3b. Mapping service is unavailable and system displays error message.
4a. Data is not available for default zoom level and system displays map at next highest available zoom level.

- Special Requirements:
This portion of the application must be accessible (508 compliant).

Now that we've had a chance to see the structure of a formal use case, we'll next look at how to start writing these use cases for an application.

...

[artcraft]

Forming Use Cases
Now that you've seen how to write a use case, it follows that you'll want to know how to start forming these use cases. For example, what level of granularity is appropriate? Should you have ten uses cases or a hundred? The answer to these questions is subjective. There is no one correct set of use cases for an application. However, you will likely find the following guidelines to be helpful:

Determine the types of users. An application can have many types of users. Each user will have different use cases. A simple example is one in which an application has a standard, anonymous user type and an administrative user type. The administrative user typically expects additional features that are not enabled for standard users. Your application might have additional tiers of users as well. For example, in addition to standard and administrative users, your application might have registered users who have access to features not available to standard users.

Determine the basic goals each type of user can achieve. For example, all users might be able to generate maps, but only registered users can save maps. Additionally, only administrative users might be able to view the logs and analytics for the application.

Fill out each use case with the appropriate sections.

Evaluate the use cases. It's important that you take your time with the use cases to make sure they are correct and appropriate before moving to the design phase. Getting the use cases correct helps ensure the best possible result of the design and implementation phases. It's much easier to make changes to the use cases before you've designed or implemented the application than to revise them afterward and have to redesign and re-implement the application.

Using UML in Analysis
UML (Unified Modeling Language) is a language in common use for modeling applications. Although UML is perhaps most frequently used during the design phase (as we'll see in the next section) it is not uncommon to use UML during analysis as well. One of the three parts of a system model in UML is what's called the functional model. The functional model allows you to create use case diagrams, which can be very helpful. UML use case diagrams generally are not detailed enough to be used apart from written use cases.


следующий раздел еще интереснее - The Design Phase :~)
и там написано про бумагу...

[iNils]

artcraft, разместить просто txt файл сложно?

[дядя Джо]

Было дело, даже книжку прочитал.
Объектно-ориентированная разработка - это концептуальный процесс, независимый от языка программирования, по крайней мере, до последних этапов. Фактически это образ мышления, а не методика программирования. Главное преимущество объектной ориентированности состоит в том, что она помогает тем, кто пишет спецификации, разработчикам и заказчикам ясно выражать абстрактные концепции и обсуждать их друг с другом. Таким образом облегчается составление интерфейсов и конечно же, программирование
Очень познавательная книжка (http://www.oz.by/books/more1025663.html) оказалась :)

[Dimchansky]

и GoF, и Фаулер и Кириевски - все переведено.

GoF (http://tk.com.ua/book_con/16021.htm)
Архитектура корпоративных программных приложений (Fowler) (http://tk.com.ua/book_con/10566.htm)
Кериевски Джошуа "Рефакторинг с использованием шаблонов"