Tietojärjestelmien peruskurssi Software engineering Malin Brännback Software Engineering Use of sound engineering principles good management practice applicable tools and methods for SD Before it was more like ad-hoc SE More disciplined approach to programming increase time devoted to program design increase productivity through savings in testing and maintenance gooddesign, good documentation, and general control of the project IRACI Begin with the idea where do ideas come from? Don’t ask what should this screen look like or What should this system do? Turn them into: What can we do to increase sales? How can we improve productivity of our sales force? How can the user best work with this information? Instead of how can this be done better? Ask how can this be done worse! Idea Be illogical try something different - instead of technical journals; try a toy catalogue visualise the process form a mental model, walk through the model, diagram the problem on paper The examples: imagine you are the kid playing the game; contact management system; imagine you are the sales person Idea Break the bounds - why is there a Save button? Talk to someone Brainstorm Relax Formalise and evaluate Formalise and evaluate Does it make sense? Does it fit with the Enterprise-wide or marketing goals What risks are involved What benefits are provided What are the projected costs Which idea is best Establish the Requirements = conceptual design goal-centred instead of user-centred create the project team Creating the Project team The entire definition and direction of the project will come from the project team significant responsibility must be carefully selected teams should include users, because they know the business - they are domain experts Selecting the team members Too many cooks spoil the broth too many designers spoil the design still, when time limits become stressed the problem is solved with adding manpower, like dousing a fire with more gasoline, keep the team small enough to collaborate effectively The project team A full team with full responsibility Then, a core team to do day-to-day work of the project not more than 5-6 persons If the project is very large, break it down into smaller pieces with one small team assigned to each pieces The full team Steering and oversight committee; representatives from all areas that are directly or indirectly affected regular meetings, responsible for communicating to their departments access to all project documentation minimally, users and technical staff ideally; current and present users, managers of these, support staff, subject matter experts, SW analysts, designers, developers, SW quality control, technical writers, technical support staff Team members and responsibilities Record keeper;maintains the formal project documents, requirements specifications, architectural design documents Project manager;directs the project, decides when to bring in specialists, etc. Decision maker; provides the authority to make final decisions “Evangelist”;the domain expert with the vision - keeps the project in focus Setting the scope The scope identifies and limits the business or functional areas affected by the application - application domain how does the AD inter-operate with other products when defining the AD keep the project goal in mind. Only those related to the goal should be included - not something for everyone Identifying the needs What the business needs to achieve and what the user needs to accomplish task analysis - spend time with the users Specify quality standards On top of basic business needs ease of use conformity to established user interface conventions maintainability reliability performance acceptable defect level compatibility with other systems Defining the technical and marketing specifications Minimal required hardware configurations Recommended operating systems network configuration language, database portability, reusability number of users, volume of data Defining the technical and marketing specifications Security requirements interface to other systems current technical standards time to market internationalisation Prioritising the requirements Quality schedule features Pick two of these. There is a trade-off, e.g. high quality and tight schedule - trade off the features list “you must have the new accounting system installed by the first quarter” 10 Myths of project planning and scheduling We have no time to design the application we will save time and money if we jump into the code stepping into a train without having time to travel! Scheduling is for the birds toplan for a certain amount of time make sure there is room in the plan 10 Myths of project planning and scheduling Estimates are certain estimates are estimates to help convert numbers on a schedule, define risk factor add time based on the risk make room for changes in the plan 10 Myths.. 8 hours = 1 Day Keep two sets of schedules Pump up the pressure there is a difference between “How can I best implement this?” and “What can I throw together the fastest If the project is behind, add programmers the project falls apart - look at the why and fix the if why, Don’t just add resources 10 Myths.. If we leave Chris alone it will get done is always a Chris who can walk on water; only there everybody else is keeping Chris busy for technical advise Interim Releases are a waste of time how “done” are things We’ll Catch up!
Pages to are hidden for
"tipe4"Please download to view full document