Обычные начало
| Эта работа относится курсы | Системный анализ и проектирование |
|---|---|
| Там, где это требование в работе | Эксплуатационные требования |
| Название команды | Грейпфрут Три мушкетера |
| Цель работы | резюме отзыва |
| GitHub адрес | Золотая точка игры |
список игроков
| член | Student ID |
|---|---|
| Чжоу Го (лидер) | 201731062630 |
| сегмент Сяоган | 201731062317 |
| Лю Ци | 201731062413 |
текст
Руководитель: Чжоу Го
адрес блога:
Student Количество: 201 731 062 630
первое соединение блог
Одна проблема: В четвертой главе «два сотрудничества» упоминается парное программирование идеи, что программист бок о бок, в равной степени, комплементарный к деятельности по развитию. Они сидели бок о бок в передней части компьютера, использовать один и тот же дисплей, с помощью мыши, клавиатуры ... «Короче говоря, при правильном использовании, программирование пара может достичь более высокого коэффициента ввода-вывода.» Однако, для больших масштабах, даже для средних проектов, парное программирование пропагандируемой компьютер, монитор, мышь модели развития, на самом деле применить его? Возможно, в небольших проектах в два человеческих общении и понимание некоторой помощи для разработки проекта и спецификации, но люди не машины части, под высоко централизованной моделью развития, два человека эффективная эффективность развития также сильно ограничена по времени , то узел в конце концов, это применим к условиям, в которых идеи и концепцию программирования это?
Парное программирование было отсутствие глубокого понимания, более жесткий. Теперь выясняется, что парное программирование гораздо больше, чем только два человека, с которыми сталкивается же компьютер, клавиатура ... программирование, парное программирование для продвижения себя не является достаточно большим для крупномасштабного проекта с точки зрения окружающей среды в высокой концентрации время и планы работы, в течение относительно короткого периода времени, как можно быстрее, эффективное завершение проекта, поэтому полноценный отдых и краткосрочное развитие, что парное программирование для небольших проектов, это действительно модель развития хорошо.
Вторая проблема: В книге 137, Раздел 7, «реальный проект программного обеспечения», упомянутая в книге «Члены команды должны иметь консенсус: для предотвращения возникновения дефектов стать основной целевой группой контроля качества, все символы должны быть по качеству ответственность за защиту.». Если качество инвестиций этого процесса, чтобы избежать большего числа сотрудников для работы в условиях полного антагонизма, повысить интерес индивида в работе. Но разработчик выдвинул более высокие требования к обеспечению качества, будьте задачами, тестеры поэтому становятся менее важными, чем? Может быть, вы можете сказать, такой подход является ли палка о двух концах, но уменьшат точку противостояния между тестерами и разработчиками в какой-то степени, но и снизить нагрузку на тестеров, так что гораздо меньше ошибок, тестирования персонала поэтому работая интерес будет уменьшить его?
Мир всегда будет несколько оппортунистических людей. В процессе нашего развития, мы должны сначала убедиться, что наши члены должны иметь определенную прибыль. В полном процессе разработки, так что все игроки несут ответственность за обеспечение качества, так что разработка и тестирование персонала имеют одинаковый интерес к разработке, на самом деле хороший подход.
Вопрос три: В главе 16 «IT-индустрии инноваций,» Я читал немного неровные содержание этой главы, в документе упоминается «инновация является ключом» для конкретной области, поскольку технология производства значительно повышение эффективности предприятия, или делает жизнь людей более удобным, мы называем инновации. Но для командного проекта, для разработки программного обеспечения, в дополнение к технологическим инновациям, а также обстоятельства, при которых он рассматривается как инновационный?
Совершенная техника, не только потребность является внедрение новых технологий, но также необходимо развивать высокую эффективность, высокую степень прилегания проектной команды, это процесс разработки программного обеспечения, что нам нужно к лицу.
Вопрос четыре: двенадцать глав «пользовательский опыт», книга упоминается важность внимания разработки программного обеспечения на пользовательском опыте, «рассмотреть пользовательский опыт различных углов, уровень дизайна, шаги и цели, когнитивный сопротивления, пользовательский опыт измерения, эмоциональный дизайн, кросс-устройство пользовательского опыта ". Затем процесс развития команды проекта программного обеспечения, роль которого должно быть описан как портрет пользователя, последовательного дизайна пользовательского опыта, и они преобразовали дизайн конкретных функций для инженеров касаются и добиться?
На протяжении моего первого блог проблемы, на самом деле большинство из них представляют собой программные вопросы реализации инженерного проекта в процессе, после окончания курса, я постепенно понял, что, потому что я не испытал весь процесс разработки проекта, наличие этих вопросов будет в том числе и этот вопрос - спрос системный аналитик, в основном, менеджеры по продуктам и менеджеры проекта стыковки, идеи продукта в конкретной функциональной реализации.
Вопрос 5: В примерно следующим образом: «Строительство закона - современная программная инженерия» После этой книги я узнал много, со мной в прошлом, программа работы группы, опыт точка команды проекта зрения, я нашел все больше и больше отличная команда разработчиков проект строительства и управление, как комплекс, в обществе, каждый интернет-бизнес, по крайней мере, есть команда программного обеспечения проект работает над программным проектом, который действительно может сделать успешную команду разработчиков проекта по созданию подрывной супер программное обеспечение, команда проекта за жалованье более трудно себе представить. Это приносит мне некоторые сомнения, если идея проекта настолько важна, что это реальность, потребность в большем количестве студентов, чтобы проводить больше времени, чтобы продолжать более высокий уровень технической теории это?
Перед чтением более жесткой, желая, чтобы сделать вещи легко, теперь я понимаю, что, возможно обучение «не может иметь как рыбы и лапой медведя» иногда неправильно. Теория основана на практике, а не теории и технологии более высокого уровня, он не существует по-настоящему подрывное программного обеспечения супер, есть не обязательно естественная и упорядоченная команда разработчиков за системами управления проектами разработки программного обеспечения.
Будь или не новая проблема:
Под влиянием этого курса это системный анализ семестра и дизайн, у меня есть проект полного процесса развития имеет приблизительное представление и знание. Но это заставляет меня больше сомнений и больше интереса к реальному развитию бизнеса,
После этого семестра, которые не были ранее освоенной навыки:
Блог, развитие команды проекта, парное программирование, и так далее.
Краткое описание:
С окончанием курса, который также близко к концу семестра. В этом проекте мы имеем практику команды, от начального до завершения создания предмета, осуществлять реализацию проекта и кодирования, для текущего проекта, члены команды проекта мы работаем вместе - все вместе, рука об руку. Очень счастлив, как лидер команды роль в этом проекте работе, мы проецируем команду Хотя только три человека, в самом начале проекта, наше техническое направление также не в данной области техники, она находится в процессе реализации проекта мы столкнулись трудности и препятствия. Но очень рад, мы наконец-то закончили его вместе. В ходе этого курса и проектов осуществляются в сотрудничестве между заставил меня понять, самый глубокий, чем команда, члены проектной группы, прежде, чем, возможно, мы привыкли к этому индивидуальному кодированию, но в ходе продолжающихся усилий команды после практики Я пришел, чтобы понять важность совместной работы в связи, в течение двух месяцев, у нас есть свои собственные силы в одиночку трудно осуществить, поэтому среди членов команды проекта должны быть больше общения, больше обменов, чтобы сделать проект более плавно преследовали.
Пользователи: сегмент Сяоган
адрес блога: https://www.cnblogs.com/dxg123/
Student ID: 201731062317
Первый вопрос, поднятый в частном месте работы:
Для того, чтобы ответить на вопросы , поднятые его прошлого:
: Одна из проблем
Это программное обеспечение для программирования, мыслящий область P48 глава инженер +3,2 программного обеспечения, анализ паралич, неуместны приоритеты, пытаясь решить все проблемы с зависимостями, как рано оптимизация, преждевременное обобщение проблемы , которые могут возникнуть, но наш новый «инженер - программист» это как справиться с этим хорошо?
A: На самом деле эта проблема, лучшее решение будет сначала сделать хороший анализ требований рабочих мест, четкое понимание задачи является более важным, и развернуть еще раз, чтобы завершить задачу, в самом деле, что вы несколько раз основных задач проекта, опыт усиления, и вы, естественно, иметь более четкое представление о задачах проекта, и наша команда, мы можем обсудить, а затем разделить задачу подробно, это может повысить эффективность.
Вопрос два:
чтение 4,5 парного программирования, на Р79 страницы прочитать содержание выше, говорят авторы, «все аспекты программирования пары, потому что в любое время для просмотра и обмена качества во всех аспектах программы будет зависеть от одной пары программистов более высокий уровень», то есть в процессе программирования программистов высокого уровня в качестве лидера. Тогда программа изначально , как мы должны быть в состоянии назначить работу для того , чтобы это имеет качество и количество для выполнения задач программирования, но также позволяет двум людям возможность участвовать в коде запрограммировали их , чтобы получить упражнение это?
Ответ: Этот вопрос, в фактической реализации проекта, не является идеальным решением, так как два человека, парное программирование, то невозможные задания 2-х человек и сложность задачи точно так же, там есть уже пара после программирования опыт, на мой взгляд, в первую очередь мы должны сказать, что они знакомы с техническими аспектами и с какой стороны они хотели сделать задачу, а затем на основе 2-х человек мощности, предпочтения, специализирующихся на поверхности, чтобы разделить задачи, так что вы можете быть уверены, что если задача выполнена, но и упражняться.
Вопрос три:
выступая в главе 7 разработчиков и тестеров будет производить противоречивые эмоции, такие противоположные эмоции в течение короткого времени может стимулировать энтузиазм членов, а затем будет долгосрочным вред. На самом деле, если разработчики и тестировщики имели противоположные эмоции, как мы должны посредничать? Оба уколоть друг друга, по существу , помогая компаниям , ищущим программных проектов и решать проблемы, то мы можем найти способ , который способен стимулировать энтузиазм к работе по повышению персонала, но и устранить противоречие между ним?
A: На самом деле, в этом, конечно, наша группа в дополнение к самому персоналу является разработчиком, который также тестер, так что не было никакого противоречия На самом деле, я, как, в полк также более расслабленным и гармоничным, посмотрите на меня примеры выше книг, и поиск в Интернете смотреть что-то, в котором кратко некоторые из методов. 1. гуманного управления является одним из способов персонала мотивационного; 2. Предоставление стимулов; 3. Расширить много встреч и групп, чтобы построить линию.
Вопрос четыре
в 11.5.5 Xiaoqiang ад (Bug ад), то считается , что так больше игроков , чтобы сконцентрироваться на ремонт Bug Bug, а не разрабатывать новые функции. Для того , чтобы избежать «Сяо Цян» стал монстром, а не просто , чтобы закончить работу, будь то небольшая ошибка, то как лучше компромисс между качеством, график, стоимость его три?
Ответ: Стоимость управления проектами, качество, время является треугольником, который должен весить баланс в его жизненном цикле на протяжении всего проекта. Под предпосылкой времени и гарантированного качества, мы считаем, что она должна быть по самой низкой стоимости ресурсов в основной цели управления проектами. Но дело не может быть достигнут во время, вероятно, для того, чтобы обеспечить качество, мы только развертывание большего числа сотрудников, работа пика, это может привести к увеличению расходов, или в случае разрешения, соответствующие требования более низкого качества, не могут увеличить по завершению стоимости проекта. Короче говоря эти три элемента очень важен в управлении проектами, важно признание.
Вопрос 5:
16,2 инновация возможность, учитель Цзоу Янь упоминается в книге игра золотой точки, вклад опыта: победитель получает все, богомол пытается остановить машину, только первый шаг, подчеркивая ложь успеха в сроках новой технологии, сроки введения слишком рано, это может быть время , чтобы утонуть, то ситуация хорошо , как время? И как помочь ему на практике и инновационных технологий в области программной инженерии?
A: Как воспользоваться возможностью это на самом деле не ясно, но я думаю, в первую очередь, чтобы иметь достаточно запас знаний, чтобы расширить свои знания, развивать далеко идущие видения, легко найти время, чтобы сократить, но и для их способности подняться, чтобы воспользоваться этой возможностью парение, я думаю, что если не хватает их собственной способности, даже нашел возможность делать плохие вещи, может быть. На самом деле, наш студент, чтобы практиковать технику, лучшее сочетание вещей в жизни, и тех, кто вокруг вас, потому что вы не в других областях тоже хорошо, и наша собственная техническая школа не так сильна, начало или от мало общего так как, делая небольшие проекты или что-то, старая поговорка гласит: «» путь, шаг за шагом, заикание риса ".
Мастер новых навыков:
Во-первых, понять тест, во-вторых, знать потребности анализа проекта и третий, чтобы понять, работа в команде. Потому что когда испытания работы друг друга, так что идти, чтобы понять и узнать, тест знаний, а также использование соответствующего тестирования программного обеспечения, а другой, когда мы делаем проект, шаг за шагом план, чтобы следить за ходом начала развития делать, естественно, медленно освоил его.
Опыт работы:
К этому времени реализация проектной команды, я глубоко чувствовать себя важной и коллективную работу, благодаря команде, не платя зарплату, я не знаю, где пациент тщательно, как я объяснил, на этот раз не только понять некоторые Java и тестирование производительности веб, но и понимать важность написания хорошего документа, в то же время получить тренировки и расти, улучшает способность к обучению, но и расширить наше мышление, наша общая цель культивировать командный дух. Тема начата, чтобы все члены нашей команды знают, как начать, через член команды вместе, чтобы найти нужную информацию, а совещание для обсуждения, мы определили цели разработки и реализацию разработки конкретной, в том числе, как использовать идею Java для детального проектирования реальной системы дюйм
- Член команды Лю Ци
адрес блога: https://www.cnblogs.com/liuhanhan/p
Student ID: 201731062413
Ссылка на блог , чтобы задать вопросы
Вопросы:
: Вопрос один
персонал управления источником, с разумным персоналом, бегущие друг друга детали. Члены команды имеют проблемы и своевременную обратную связь.
Вопрос два:
относится к подобным пунктам, потому что мы не знакомы с соответствующим проектом для отдыха времени, если изменения спроса в то время , чтобы внести соответствующие изменения.
Вопрос три:
атмосфера команды очень важна, П.М. вовремя , чтобы иметь возможность слушать ваши мнения и отзывы, дизайн проекта, соответствующий фазовый анализ позволяет разработчикам участвовать.
Вопрос 4:
разработка и тестирование проводится одновременно , а не позднее разработан в ходе испытания. Важные особенности требуют полного аудита кода, а другие , как в случае , может быть.
Вопрос 5:
Я думаю , что это не так. Если не специалист, по крайней мере , есть также значительное понимание и знания в этой области. Не слишком много вещей, так каждый шаг трудного энтузиазме скоро рассеются, обычные вещи , как правило , не делают, чтобы не говорить об инновациях.
Новая проблема:
документ может быть упрощен или без? Изучение различных направлений, различный прогресса обучения, различные точки интереса, и даже узнать , как языки разные курсов с действующей командой студентов?
Усвоение:
Через этот семестр, в частности, через этот курс, я мог бы быть на GitHub более квалифицированной работы, могут проводить анализ потребностей перед началом проекта тщательно, предварительные образцы демонстрируют использование чернил ножей и других инструментов прототипирования на этапе проектирования, содействовать друг с другом посредством парного программирования и повышение эффективности программирования друг с другом на основе взаимного контроля между формованием команды проекта имеет базовое понимание процесса тестирования программного обеспечения. Самое главное, опытные процессы развития команды в процессе развития команды проекта, улучшает взаимодействие команды и навыки сотрудничества. Через семестр я получил значительно улучшился.
Обучение Резюме:
практика делает совершенным, поэтому эволюции человека, по- видимому , чтобы узнать и освоить навыки , а также. Просто увидеть много вещей , которые не могут понять, только укрепить руки может действительно квалифицированный, в конечном счете , освоил мастерство; Inf, Qinnengbuzhuo, ленивый должен научиться не имеет значения, направление очень важно, труднее , чем стоять бесцельно шаговый более пугающая --- соломинки без изнурительного дохода, что является причиной , почему некоторые люди говорят , что выбор больше усилий. Семестр закончился, но наша карьера и жизненный путь только начался. Я считаю , что мы урожай более полный парус.
Сохранение данных команды
см Github ~ вы пройдете →