1. SHDLSTUDIO Presented by : AL SAATI Razann BARDET Marine
EL AOUYED El Mehdi
ESSAID Sanaa
FANGAR Mohamed

2. Plan Introduction Legacy New Specifiation Work Organization
Development approach
GUI Amelioration
Bug List and Test procedure
Quality management
Conclusion

3. Introduction Language used for logic circuits simulation
SHDL Language : What is the SHDL language ?
Language used for logic circuits simulation
Simple Hardware Description Language
This language is used for teaching purposes at ENSEEIHT (easier than VHDL)
Created by Jean-Christophe Buisson, researcher at IRIT laboratory.
An Older Software (MDLE) was developed ten years ago. (reference for the project)
Project began in 2010 : 3rd development team.

4. Introduction module fulladder(a,b,c:s,r)
s=a*/b*/c+/a*b*/c+/a*/b*c+a*b*c;
r = a*b + a*c + b*c;
end module

5. Legacy Software: Documents: Maintenance Manual not provided.
SHDLStudio
Documents:
Report
SoftwareDevelopmentPlan
SoftwareQualityRequirement
SoftwareRequirements
SoftwareValidationRequirement
Maintenance Manual not provided.

6. Work Organization and environment
Java - Netbeans 6.9.1
Environement :
Origo - Subversion
ENSEEIHT – Room A-204

7. Project Management Client Meeting: Change control Board Reviews
Supervisor Meeting:
Progression of the project
Software documents
Software Quality approach
Team Meeting:
Work Organization
Client and Supervisor requirements.
Project status
Client Meeting
Team Meeting
Supervisor
Meeting
Daily work : everyday from 10:00 am to 6:00 pm room A-204 (basement Bat A.)

8. Development approach
GUI modifications and correction of bugs: incremental cycle

9. Development approach
virtual objects:

10. Risks and preventive actions
Requirements Volatility
Frequent review with the client
Frequent team meeting
Technology unknown
New task : appropriate code
Make prototypes

11. Planning

12. Client Requirements Correction of bugs Virtual Objects
(Lift, Oscillator, 7-segment Display)
Amelioration GUI
(Design, Chronogram)
Document
(Maintenance Document)

13. BUGS Check functionalities Establishment of a list Resolution of them
We started to check functionalities when we received the latest version of the software.
With results of theses checks we establish a bug list (formalized in a document for the bug part) in a shared file.
Along the project we tried to solve the most important whose multi-view exception (which allow the user to open several modules)
Resolution of them

14. Virtual Object
Electronic system, whose behaviour is simulated by the software
3 required objects :
Lift
Seven Segment Display
Oscillator

15. Lift Simulation Code SHDL: new Module(a,b:c,d) lift(a,b:c,d);
end module
Design

16. 7-Segment Display Design Code SHDL: new Module(a[7..0])
afficheur7seg(a[7..0]);
end module
Simulation

17. Oscillator Design Code SHDL: new Module(a:b) oscillator(a,20:b);
end module
Design
frequency
Simulation

18. GUI Amelioration : Simulation and Chronogram
Modification of inputs values
Modification of signal value during the simulation
Modification of the Chronogram display
Displayed Signals in Chronogram : not yet implemented

19. Design amelioration: Comparison
GUI Modifications: 
Design amelioration: Comparison

20. Design amelioration: The magnetic grid
GUI Modifications: 
Design amelioration: The magnetic grid
One step (s)
Operator location
One step is a multiplier of this distance (h)
S=h x 4

21. GUI Modifications: Design ameliorations Hidden input connection points
Inputs operator labels
Different colours for input and output labels
The radius of points had changed
Different lines depending on the arity

22. Test procedure General check at the beginning
Integration test for virtual object (use in edition and behavior in simulation)
Functional tests
Tutorials
As I said we made a general test of functionalities to see what was already implemented in the software.
For each virtual objects we made integration test.
We tested the object itself, the use in source view, design view and the behaviour in simulation
At the end with the software requirement documents we test each requirements written in the SRD.
The results are met in a table. This way, the following group will have a structured basis.
To finish we make a global test, by doing the tutorials of architecture module at ENSEEIHT.

23. Test Results
Virtual object:      lift : outputs problem      7 seg display ok      oscillator : frequency problem Functional tests:      53% work well      37% not implemented yet      9% bugged Tutorial:      ok : fulladder ...      nok : flipflop+oscillator ..
The virtual object works more or less
The functional test are globally ok but there is a lot of requirements not implemented
Some bugs remain
Concerning the N7 tutorials, the first module is ok but the rest doesn't work.

24. Coding and documenting rules
The source code must obey these rules:
- R1 : Every class must be commented.
- R2 : For a package, each class contains maximum lines in average.
- R3 : Each new function contains maximum 30 lines.
- R4 : Average of cyclomatic complexity < 7.
- R5 : The document's template should be respected.
- R6 : The reference should be indicated with the number of pages.

25. Metrics results (Simple code metrics)
Packages
Metrics
Conversion
Actions
Simulation
Cyclomatic complexity average
5.27
1.27
3.12
Total LOC
1616
1054
4586
Total Classes 2 12 25
Average
808
87,8
183,44
Total Methods 35 69
193

26. Project Future Delivrables : Software Requirement document.
Development plan document.
Validation plan document.
Quality insurance plan document.
Source code
An executable of the software.
Maintenance document and User guide
Configuration management plan

27. Technology unknown : Netbeans RPC
Conclusion
constraints
Short Time :
8 weeks
Quality supervisor :
Documents needed
Technology unknown : Netbeans RPC
Client’s needs :
Source Code

28. Demonstration

29. Thank you for your attention