Project Definition: Key Points Milestone 2 and Group Management Issues

 

Product Name System Description

A high level description of the system from a business and user perspective. Describe the business opportunity for the product, and why it differs from what currently is in the marketplace (if possible). What problems it will solve for the target audience? What competitive advantages does it offer? How can it improve efficiency, effectiveness or workers?

Business Case

  

Project Definition: Key Points

Project Definition: Key Points

User-level goals for the system

Project Plan/Rough Estimates
 

State the main expectations and requirements the user will have for your system For every main user task that involves your system, describe a realistic scenario that shows when the user will use the system and what for Describe what your system will and will not do when it is finished. Be careful to make the scope match with what your estimated budget.

User scenarios

Break down the project into individual tasks, and For each task, provide a rough estimate of the number of hours it will take to complete. Write a plan for how you intend to involve users Including which users you will involve, how much of their time you will need, when you will need it, and why

User involvement plan
 

Scope document


Project Definition: Key Points

Project Definition: Key Points

Low fidelity prototypes

Project Plan

For each of the main interfaces, provide a pencil or whiteboard drawing of it showing your approach to design Consider these UI designs preliminary, for discussion purposes, and by no means final Include the number of hours that group members have spent on various tasks Including meetings and all overhead and administrative time Identify any risks that may affect project success (on time, on budget, with all in scope features included). 5

Provide a list of who did what for this milestone, and who will work on what for the next milestone

If work is done in group, just write “done by group”

 

Project management report

At this stage, most activities will be group activities Provide expected dates of completion and expected effort in hours

 



Project Definition: Key Points

Manage your own project
  

Quality Assurance Plan

How will you ensure that you produce a quality product?

  

Usability. (e.g., Meetings with key stakeholders. Review of product requirements with primary stakeholders. Walkthroughs of paper prototypes. Testing of product.)‫‏‬ Maintainability. Robustness. Correctness.

Consider your own project Need to manage it properly if you are to be successful What are the keys?
     

Using good group management techniques Good planning Defining appropriate scope Estimating costs (measured in time in this case)‫‏‬ Constant care throughout the project Flexibility

Agile response as deviations to the plan occur

 7

Let’s look at some of these issues since they occur in all software projects

Necessity of Working in Groups

Group Management Models

All large software systems are built by groups
 

Democratic decentralized

Too much for any one person to do Group management thus becomes a critical determiner of success

no permanent leader, but task coordinators for important tasks decisions made by consensus there is a defined overall leader group problem solving

Basic trade-off

Controlled decentralized
 

Must agree on the need for coordination and cooperation

to keep the whole project on track with the need to separate tasks and goals to allow the various parts of the project to get done

but responsibility for subtasks assigned by the team leader

Controlled centralized
 

one overall leader coordination at all levels managed by this leader

Choosing an Appropriate Group Management Model for Your Project

Proven Coordination Techniques

Which of these models is most suitable given the constraints on your project?

Formal group meetings
 

Since we want everybody to practise as many aspects of the software engineering processes discussed in the class as possible and since all team members are equal, it must be democratic decentralized

can be virtual but more value in physically collocated meetings requirements design code short, frequent meetings (15 minutes - don’t exceed)‫‏‬ recent progress, immediate next goals can sometimes use technology such as e-mail and 12 moodle

Frequent reviews
  

Such a decision itself has implications, even as to the architecture of the system

want to foster what Herb Simon has called “near decomposability” in the system design

Frequent discussions
  



Problems with Working in Groups

How to Avoid Difficulties when Working in a Group
 

Bad characteristics of group members (from surveys of previous
years’ students in u/g software engineering courses at U. of S.)‫‏‬
         

Lazy or apathetic people – 84% Unorganized, irresponsible, unreliable people – 57% People who are always right: selfish, pushy people – 37% Uncooperative, disruptive, obnoxious, negative people – 25% Inflexible, close-minded, unimaginative people – 21% Unintelligent people, people lacking skills or knowledge – 19% People with low ethical standards, dishonest people – 18% Shy, scared, uncommunicative, unsociable people – 12% People unwilling to share information and work in groups – 10% People with no interest in high quality work - 9% How do you know ???-I believe NOT!!

Personal responsibility Project architecture that allows
 

Fewer person to person interactions Clear identification of each person’s responsibilities/ accountability

  

Communication, communication, communication, … Good planning A sharing/caring attitude
 

no prima donnas, no massive egos everybody must do their share: can’t have people hog the entire project or avoid their duties talk out problems if necessary seek help from peer, tutor, or professor

Don’t let problems fester
 

Do any of these characteristics describe you ???


Sign up to vote on this title
UsefulNot useful