1 / 15

Flow Practice

Learn the key factors in creating good requirements for software development projects, including correctness, clarity, consistency, verifiability, traceability, feasibility, and more. This guide provides a checklist and practical tips for improving your requirement gathering process.

lillis
Download Presentation

Flow Practice

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. Flow Practice Software Development Flow

  2. Modeling Iterative Development • Identify requirements • Create an architecture • Implement features • Verify features • Deployment • Maintenance • Use iteration as much as possible

  3. What makes a good requirement • Is the requirement correct? • Does the requirement specify a true need, desire, or obligation? • Have you identified the root cause that necessitates the requirement? • Is the requirement complete? • Is the requirement stated as a complete sentence? • Is the requirement stated entirely in one place and in a manner that does not force the reader to look at additional information to understand the requirement? • Is the requirement clear? • Is the requirement unambiguous and not confusing? • Does everyone agree on the meaning of the requirement? • Is the requirement consistent? • Is the requirement in conflict with other requirements? • Is the terminology used consistent with other requirement and glossary terms? • Is the requirement verifiable? • Can you determine whether the system satisfies the requirement? • Is it possible to define a clear, unambiguous pass or fail criterion? • Is it possible to determine whether the requirement has been met through inspection, analysis, demonstration, or test?

  4. What makes a good requirement • Is the requirement traceable? • Is the requirement uniquely identified so that it can be referenced unambiguously? • Is the requirement feasible? • Can the requirement be satisfied within budget and on schedule? • Is the requirement technically feasible with current technology? • Is the requirement physically achievable? • Is the requirement design independent? • Are all requirements that impose constraints on the design, thereby limiting design options, justified? • Is the requirement stated in such a way that there is more than one way that it can be satisfied? • Is the requirement atomic? • Does the requirement statement define exactly one requirement? • Is the requirement statement free of conjunctions (and, or, but) that could indicate multiple requirements? • http://www.utm.mx/~caff/doc/OpenUPWeb/openup/guidances/checklists/good_requirements_594ACCBD.html • http://tynerblain.com/blog/2006/05/25/writing-good-requirements-the-big-ten-rules/

  5. Requirements – To-do list • The program should contain the following components: priority, deadline, name of the task, short description, status, type f the task, date of creation, additional note. • The program should be editable online. • The program should be secure and password protected. • The program should sent reminder or notification when deadline is near. • This list should have the opportunity to export the list to a file. • The property status have three opportunities: not started, in progress, done. • The property type has three possibilities: personal, work, meeting. • The property status and type have color indications. The different type of properties are indicated by different colors. • After program is restarted list should be retrieved. • Command line user interface should be implemented for all features. • When the date of the event is the same than the date of the day you will get a notification alert. • You can edit the previously made events. • List the events according to cohsen time period (for example week, day, month). • Store the events that you have already done for required time period. • You can check out the event you have done. • You can give priority on 1-5 scale for events. • You can list according to priority or time schedule. • The program can accessed as owner or guest. • Highlight the priority levels with different colors.

  6. Requirements – To-do list • 1. The program should contain the following components: priority, deadline, name of the task, type of the task(short description, status, date of creation, additional note). • 2. Command line user interface should be implemented for all features. • 3. After program is restarted list should be retrieved. • 4. You can list according to priority or time schedule. • 5. You can check out the event you have done. • 6. You can edit the previously made events. • 7. The property type has three possibilities: personal, work, meeting. • List the events according to chosen time period (for example week, day, month). • You can give priority on 1-5 scale for events. • Highlight the priority levels with different colors. • The program should sent reminder or notification when deadline is near. • This list should have the opportunity to export the list to a CSV file.

  7. May be… • https://twitter.com/jakemitchell/status/499258805285183488/photo/1 • capn0jack ‏@capn0jack Sep 17@jakemitchell @hdmoore Yeah, right after the meetings in which someone tells you what the (…) the prototype is supposed to do.

  8. Timeboxing • 20’ Identify requirements in 2 groups • 5’ Prioritize together • Create backlog • 20’ Create an architecture in 2 groups • Define “objects” and interfaces • 10’ Agree on interfaces • 70’ First round on development • 2 development teams, 1 integration and verification team (I&V) • 10’ Backlog creation • 50’ Development • 10’ Evaluation • Break • 70’ Second round on development • 2 development teams, 1 integration and verification team (I&V) • 10’ Backlog creation • 50’ Development • 10’ Evaluation

  9. ExamplesNot Formulated Requirements • Add/remove todo actions • Add/change priority • Store date when action added • Set to “done” • After restart list should be retrieved • Print all items at once in priority order • Search for words • Filter to words • Filter to priority • Command line user interface • Graphical user interface • What is needed on the GUI?

  10. ExamplesArchitectural Desicions • Command line format • todo add action • todorm index • todo list • … • Interfaces, source code structure • list.hlist.c • Int add( … ) • void rm( … ) • char* get( … ) • pri.hpri.c • file.hfile.c • Save( … ) • Load( … ) • main.c • Command reception

  11. Team setup • Team #1 Dev1 • List implementation • Team #2 Dev2 • Command line parameter handling • File handling • Team #3 I&V • Setup folder structure in fossil • Integrate using script • Write automatic test code • Write regression test

  12. ExamplesProduct (High Level) Backlog • Define list interface • Implement list storage object • Implement command line parser • Document command line parameters • Implement list action callers • Implement printout • Implement file save • Implement file read • Define file read-write interface • Setup Chiselapp • Integrate all -- build from command line • Automatic test cases for list object (through interface) • Automatic test cases for file object (through interface) • Automatic test cases for the whole system (through command line) • <Prioritize here>

  13. Tools • http://chiselapp.com/ • issystem@freemail.com • password: ISSYSTEM • group1 • repository: Issystem • fossil.exe clone http://chiselapp.com/user/group1/repository/Issystem issystem.fossil • http://chiselapp.com/user/group1/repository/Issystem/login • CodeBlockshttp://sourceforge.net/projects/codeblocks/files/Binaries/13.12/Windows/codeblocks-13.12mingw-setup.exe= http://goo.gl/oGlnus • Fossilhttp://www.fossil-scm.org/download/fossil-w32-20140612172556.zip= http://goo.gl/PoLw5a

  14. ExamplesRequirment discussion • Synchronize folders among different systems • Linux, Android, Windows, Mac support is needed -- same functionality • Is GUI needed? • Common folder where shared content should be copied • Or add any folder and synchronize • Server needed where the most updated content found • Or fully distributed setup • SSH • Encryption on server is needed? • Encryption on client is needed? • Every client uptodate every minute -- service is needed • or just manual update • or configurable update • Service should not take more than 0.5% processor time in idle • Sync should not use more than 20% processor and 20% disk access resources • Should it work behind a firewall? • Private and Public keys are generated automatically • How to fix private key distribution

  15. Assessment Description Questionnaire (“free answer” type) about below topics • Continuous integration • http://martinfowler.com/articles/continuousIntegration.html • http://en.wikipedia.org/wiki/Continuous_integration • Revision control • PPT in http://uni-obuda.hu/users/boraros-bakucz.andras/index.html • http://en.wikipedia.org/wiki/Revision_control • Fossil commands, usage • Iterative development • PPT in http://uni-obuda.hu/users/boraros-bakucz.andras/index.html Essay about… • Software architecture • Read 10 chapters from 97 Things Every Software Architect Should Know (Link) as preparation • Take notes on paper during preparation • During the face to face exam, write an essay on paper about what you learnt “Essential topics for software architecture design” (~50 min, 3 pages) • You can use your paper notes made earlier, during preparation phase • Be smart, do not give automatic reproduction of the text you read, give a summary plus own thoughts Both needs to reach level 2 (satisfactory), and contribute 0.5 multiplier in the final mark.

More Related