1 / 24

Tietojärjestelmien peruskurssi Software engineering

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

tia
Download Presentation

Tietojärjestelmien peruskurssi Software engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Tietojärjestelmien peruskurssiSoftware engineering Malin Brännback

  2. Software Engineering • Use of sound engineering principles • good management practice • applicable tools and methods for SD • Before it was more like ad-hoc

  3. SE • More disciplined approach to programming • increase time devoted to program design • increase productivity through savings in testing and maintenance • good design, good documentation, and general control of the project

  4. 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!

  5. 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

  6. Idea • Break the bounds - why is there a Save button? • Talk to someone • Brainstorm • Relax • Formalise and evaluate

  7. 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

  8. Establish the Requirements • = conceptual design • goal-centred instead of user-centred • create the project team

  9. 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

  10. 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

  11. 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

  12. 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

  13. 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

  14. 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

  15. Identifying the needs • What the business needs to achieve and what the user needs to accomplish • task analysis - spend time with the users

  16. 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

  17. 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

  18. Defining the technical and marketing specifications • Security requirements • interface to other systems • current technical standards • time to market • internationalisation

  19. 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”

  20. 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 • to plan for a certain amount of time • make sure there is room in the plan

  21. 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

  22. 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 • if the project falls apart - look at the why and fix the why, Don’t just add resources

  23. 10 Myths.. • If we leave Chris alone it will get done • there is always a Chris who can walk on water; only everybody else is keeping Chris busy for technical advise • Interim Releases are a waste of time • how “done” are things • We’ll Catch up!

More Related